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

[aaronysj]

之前做过的项目，基本都是用自增 id 做主键或者没有主键。这次领导突然说用 UUID varchar(36)位做主键，让小弟有点迷惑，望大家指点迷津。

[oma1989]

UUID 数据量的大话会有吃屎的感觉，别问我咋知道的。。。。。。。

[yalin]

有些场景，数据库要搞分布式。https://medium.com/@Mareks_082/auto-increment-keys-vs-uuid-a74d81f7476a

[love]

哪怕用 UUID 也不要 varchar(36) 啊，8 个二进制字节的事你搞这么大干嘛

[wysnylc]

@ryd994 #33 都说了大数据量,概率再低不是没有概率
我明确说明是大数据量就是防止你这种说概率低的抬杠,没想到你还是来了

[tanszhe]

直接搞个 id 生成服务， 和数据库自增一样的。
唯一缺点就是要单独部署一个服务

[wenzhoou]

分布式只能用 UUID 的情况。

假定我是一个公开的接口，有不特定的若干个客户端。
没个客户端给我们系统发送请求的时候，又需要这些请求记录都保存在 db 中。

这种需求就让客户端自己发 UUID 作为主键，你们随便发，保证不会冲突。

这是一种必须用 UUID 的场景。

[W1angMh]

建议用雪花算法

[passerbytiny]

@wysnylc #39 照你这“概率再低不是没有概率”的说法，下雨天就不能出门，遭雷劈的概率可要比 UUID 碰撞发生的概率高的多。抛开具体数字去说“大”，你这才是真正的抬杠。

[wangliran1121]

劣势很明显，不自增

[wysnylc]

@passerbytiny #48 爱抬你就多抬点,我当乐子看

[swulling]

uuid 碰撞和什么大数据量没关系

关键是两点，吞吐和生成 uuid 的机器

[Takamine]

我们是用的 PG 自带的 uuid 生成。_(:з」∠)_

[weiruanniubi]

求楼主头像的高清大图……

[singworld]

前公司代码规范里 禁止使用 uuid 做主键

[Cbdy]

优势是简单，劣势是性能差，而且差到在有的场景成为瓶颈

[LokiSharp]

各方面都有优势，劣势是总有人用字符串存他

[wind3110991]

如果是 INNODB 的话，索引结构是一颗 B+树，叶子节点存储的是索引的值，如果存递增的数字作为索引，那么无论是空间还是在一定范围内搜索都是高效的，如果存一段 UUID，真想不出有什么优势。
有人提到可以搞分布式+大数据量，但是 Mysql 本来就不是干这个事情的，如果是量级达到这个级别不如换成 HBase

[lishunan246]

靠 uuid 反爬根本就是掩耳盗铃。等把所有主键都换成 uuid，我想知道服务端一条日志能有多长。

[itning]

UUID 劣势是因为 mysql 索引是 B+树的结构导致的

[iluckypig]

你应该先补充一下索引结构的知识，就是到上面大家说的 UUID 索引性能差是为什么了