UUID 做主键有什么优势和劣势？

分库

不容易被人看出规律（隐藏用户数量）, 散列好,做缓存字段更好处理, 不用自增降低数据库消耗，也更适合做分布式系统主键, 长度比 int 好, 字符串做主键也不会出现 long 型导致前端 js 麻烦问题

缺点也就性能差点

*据说*，字符串的主键在某些 DB 下会有一些性能问题（毕竟数字就一个，字符串是一堆）
压力不很大的话，snowflake + big int 也够用了

优势就是唯一了，劣势一堆，字符串还是不要用来做主键的好，浪费存储，mysql 有热数据的，不利于连续的热数据加载

优势是猜不出来，劣势是采用聚簇索引时候会影响插入性能

劣势就是太长了啊，存着浪费空间。

如果是为了如 @lolizeppelin 所说隐藏规律，那可以写一个通过数字 id 加密生成一个无规律的字符串的方法。

@wd
这种做法一般得用 long, 比如上面说的 snowflake
long 在 js 上很麻烦,还要特意转为 string

uuid 这种方案其实挺尴尬的，小项目不需要，而大项目性能又不好

如果是 MySQL innodb，非自增主键空间利用率低 and 插入性能稍差
详细原因请自行了解 B+树的原理

我们是两者都有，系统内部用自增 id 做主键，系统间 RPC 用 uuid 标识唯一用户

项目大了好分库，小项目主键哪个都差不多，大项目肯定不能用自增，所以业务扩展上 uuid 比较好。说 uuid 性能问题的，你真的让 uuid 有性能影响的时候，其它地方的瓶颈才是重点……

优势就是猜不出规律

劣势就是浪费存储和索引性能

没啥优势. 推荐用趋势递增的 long 型数字.

优势:无规律,碰撞小
劣势:无规律,大数据量一样会碰撞
总结:建议使用雪花算法等解决碰撞问题

@BBCCBB 哈哈 看来我下一主题 就是怎么劝领导放弃 UUID 做主键了
@newtype0092 感谢 我在一篇博客里看到过这种

ORM 那边可以做一个 trick
类里写的是 UUID 其实 db 里存的是 big int 哒

有种东西叫做时间有序 UUID，在数据库中的性能依然很好

https://www.codeproject.com/Articles/388157/GUIDs-as-fast-primary-keys-under-multiple-database

用自增 ID 做物理主键，再加一个 uuid 做逻辑主键（加 unique 索引），在外键关联的时候用逻辑主键，这样子在分库的时候无痛， 也不会遇到 uuid 作为物理主键的时候遇到的性能问题。唯一的 issuse 就是会浪费一部分存储空间

我觉得对 UUID 作为 DB 的主键有着错误的认知，UUID 可以实现微秒精度的时间有序