关于 MySQL 建表主键用自增还是 uuid 的问题

[daoqiongsi1101]

关于 MySQL 建表主键 id 字段的类型，目前有这几种：

1. 一个自增数字作为主键 id
2. 一个无序的 uuid 作为 id
3. 一个有序的 uuid 作为 id
4. 一个业务 uuid （无序）作为 id ，一个自增字段 incr_id

InnoDB 引擎，主键 id 有序能利用其优势。

第 1 种，对于敏感的数据，容易根据 id 增长暴露增量；

第 2 种，没利用到 B+ Tree 的特性；

第 3 种，要引入 snowflake 等算法生成器；

第 4 种，其实是第 2 种的变体，加一个 incr_id 自增字段，在分页的时候用到

大家讨论一下，在 2021 年，那种主键 id 类型是推荐的？

[xuanbg]

雪花 ID

[Fly4J]

snowflake

[ylz]

第一个的问题可以用 https://hashids.org/

[love2020]

在使用 InnoDB 存储引擎时，如果没有特别的需要，请永远使用一个与业务无关的自增字段作为主键

[TUNGH]

要么自增,要么雪花

[initdada]

分布式 ID 生成器 参考 Tinyid 、Leaf

[Feiex]

既然业务 id 敏感，我推荐 3 ，加上防止回退做成 sdk 就好了，大家一起用也不用关系细节

[mokeyjay]

UUID 在实践中遇到了一些麻烦的问题
所以目前我们在建表和逻辑代码中用自增主键 id ，但这个 id 对外展示前会经过 #3 提到的 hashids 哈希后展示

[onhao]

我们是网文行业， 采用自增方式， 然后发现败的一塌糊涂， 不过在哪里摔倒就在哪里爬起来， 我们还是坚持采用自增， 不过对自增 ID 做了对应的处理， 通过自定义函数，算出一个不重复的字符串，然后创建一个视图。完美解决。

[lichao]

@mokeyjay 分享一下，什么样的麻烦？

[FawkesV]

雪花 ID 吧

[chengyiqun]

@lichao 无序 uuid 容易造成索引重排, 写入性能很低.
而自增的, 只要追加到索引的最后即可.

[zzzmj]

自增 id 再加一个 uid 索引=。=

[815979670]

用 UUID 的话可以考虑使用 `UUID_TO_BIN()` MySQL8.0 新增函数，将 uuid 转为二进制，转换后是一个 varchar(16) 的值。（做主键即能代替 id 自增，又能解决 uuid 做主键性能不好的问题）

[tabris17]

> 第 1 种，对于敏感的数据，容易根据 id 增长暴露增量；

自增 ID+hashids 加密就行了

[chotow]

分享一个从 V 友那里学到的，使用 MySQL 自带函数 UUID_SHORT： /t/802473 #1

[makelove]

uuid 太大了，不但在主表上且每个索引的每个项都会包含这个 uuid 指回主表,简直过于浪费内存
没有业务必要自增足够好了

[onhao]

可以参考下， 我们的方案 自定义函数+视图的方法 https://wuhao.pw/archives/282/

[Numbcoder]

把 MySQL 换成 PG ，就没这些月经问题了

[FallenTy]

自增 ID 作为数据库主键，再用 uuid 作为接口查询参数，自增 ID 仅用于数据库关联查询