MySQL 主键用自增好还是 UUID、雪花算法 ID 好？用自增+UUID 会不会好一点？

[polyang]

我想的是一个表有两个基本字段 id 和 primary_key，id 是自增，且为主键； primary_key 为 UUID，是逻辑主键，表与表之间通过 primary_key 来关联，对前端也只暴露 primary_key 。

[jenlors]

自增效率最高，UUID 不会暴露数据量，但是效率低，看业务场景吧

[ThanksSirAlex]

用 UUID 你要自己有一个能竟然范围查找和排序的字段，雪花算法是分布式自增 id，如果你是单机，就不需要考虑这个东西

[CodeCodeStudy]

数据量不大就不要用雪花算法了，那是给分布式搞的，数字太大，看着头疼

[emeab]

表和表直接直接用主键不也可以吗. 你对外不暴露就行了.

[xwayway]

我们现在一般是自增主键做 id，业务上设置个唯一键

[RRRoger]

postgres integer 最大是 2^31-1

不知道 MySQL 有没有这样的问题

[codespots]

@RRRoger 换 bigint 啊 2^63-1 unsigned 2^64-1

[AquanllR]

雪花算法 ID，可以兼容后期分布式架构，但是限制了 1024 个`workerID`，可以按自己业务架构定向去使用哪种方案，小项目单体自增完全 ok 。

[AquanllR]

@AquanllR 自增和雪花，都是增量的，更加适合 mysql 的索引，UUID 不太适合索引~

[Lemeng]

做的自增

[joesonw]

不想暴露数据量, 数据在后端 hashid 一下就好. 雪花不允许服务器时间有回滚的, 实施起来难度也不小.

[wei745359223]

可以用 hashid 相互转换自增 ID

[potatowish]

数据表当然是存原始数据，敏感数据 hash 一下再对外暴露

[caixiaomao]

用自增 id 比较多

[aragakiyuii]

mysql 主键 clustered index 用 uuid 简直是灾难

[Numbcoder]

UUID 这种垃圾还有人用吗，既不能防碰撞，又是无序，还占空间。
生成唯一 ID 的方式那么多，再不济自己根据业务需求加随机数生成的 ID 也比 UUID 好啊

[aragakiyuii]

@Numbcoder uuid 优势就是简单😂不过还是得分数据库，postgres 支持 uuid 类型，用 16 字节存储 binary 数据。不是聚簇索引效率不会很差，肯定比不过自增 id 就是了

[xuanbg]

自增最大的问题是想要知道 id 还要读一次。。。uuid 和雪花就没这毛病。不过 uuid 虽然简单，但是不利于索引。

so，还是雪花好了，写个雪花 id 生成器没几行代码。

[Rocketer]

千万别用 uuid，这玩意效率不高，暗坑不少。

比如版本问题，你如果用多种数据库（比如 SQL Server 和 MongoDB ），你会发现他们默认的 uuid 版本不一样，不专门设置一下就无法愉快地一起玩耍。

我现在都用雪花算法，直接用来做主键就好了，无须再多一个 primary_key 。

[jorneyr]

我喜欢用雪花，因为在业务层未插入到数据库的时候就可以生成好 ID，尤其是同一个业务中要处理多个用 ID 关联的对象，业务层可以把他们依赖的 ID 生成好直接使用，处理好关系后用事务保存到数据库。如果用自增 ID，得按照先后顺序保存到数据库并且查询得到最新的 ID，然后再处理关系，比雪花麻烦一些，业务逻辑写起来也麻烦。