关于唯一标识问题

[fiypig]

比如一个 User 表 , 这唯一标识是用自增 ID,还是账号, 还是 UUID 呢.

我的话会想用自增 ID, 但面试官说用 UUID, 自增 ID 在大并发注册的时候会产生性能问题.

而我原先的项目架构是用账号的.

麻烦大佬解答下...

[netnr]

业务系统，用 UUID ,更灵活，没保存前就拿到 ID，导入导出方便

[crystom]

注册用户都大并发那就太厉害了

[fiypig]

@netnr 还有分表的话, 是不是也用 UUID 呢

@crystom 难道我记错了..

[yrj]

如果注册量大到连自增 id 都不行，那应该有专业 dba 去解决问题了。可以试试雪花算法

[opengps]

上来就自增 id 有性能问题，这思维局限也是没谁了。
反例：我 64 个库，每个库分别 1 ～ 63 设计，都 64 步长，分库自增还不够？那我来个 1024 个库共同完成呢？

[qa2080639]

有多少个平台大到注册都得考虑高并发。果然是面试造火箭

[beidounanxizi]

面试官是 SX，uuid 会有性能问题 page split 去看看高性能 MySQL 吧

[mscststs]

user 表考虑并发的性能问题，你们是要给沙子编号吗？

[eric]

MySQL 不要用 UUID 当主键。

[hooopo]

面这种问题的面试官

[fiypig]

@yrj 我去了解下雪花算法

@opengps 哈哈哈, 我好迷啊

@qa2080639 这只是个假设的吧

@beidounanxizi 好的 , 这个我要好好查查

@mscststs 假设的啦

@eric 好的, 我知道了,但是我也要去了解看看是什么原因

@hooopo 可能看我太菜了把, 没啥问题问的, 不过也感激这次面试,有些问题勾起我的兴趣啊...

[hooopo]

@opengps 哟 自增 id 又没问题了？

[Mitt]

自增 ID 再有性能问题也不适用于 User 表啊，User 都并发注册成这样了，考虑的就不是表的问题而是恶意注册了吧

[fiypig]

@Mitt 我没提恶意注册这块,直接带过问其他问题了...

[Leigg]

考虑这个问题也太极端了，多高的并发才会关注到这个性能影响？ uuid 作为主键的缺点楼主先查查，我怎么感觉你是个刚毕业学生？

[by73]

UUID 确实不太适合作为主键，原因很简单，太长了。。另外如果是自增的话，在并发场景所有线程都需要同步访问上一个值，肯定会有性能损失的。

目前分布式的算法，一般都是基于时间戳，让每个线程不同步也能生成一个自增且概率上尽可能唯一的值。

[sapocaly]

屠龙的话:单独的 uuid service，cache 好按此 sharding，sharding table 就用 integer.
可以参考:https://instagram-engineering.com/sharding-ids-at-instagram-1cf5a71e5a5c

[fiypig]

@Leigg 哈哈哈 , 主要我太菜了, 而且 UUID 也完全没接触过...

@by73 懂了 大佬


@sapocaly 好的,谢谢啦