关于唯一标识问题

• 資深大佬 : 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 好的,谢谢啦