关于唯一标识问题

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

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

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

@crystom 难道我记错了..

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

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

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

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

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

MySQL 不要用 UUID 当主键。

面这种问题的面试官

@yrj 我去了解下雪花算法

@opengps 哈哈哈, 我好迷啊

@qa2080639 这只是个假设的吧

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

@mscststs 假设的啦

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

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

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

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

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

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

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

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

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

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

@by73 懂了 大佬


@sapocaly 好的,谢谢啦