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

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

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

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

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

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

postgres integer 最大是 2^31-1

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

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

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

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

做的自增

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

可以用 hashid 相互转换自增 ID

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

用自增 id 比较多

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

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

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

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

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

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

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

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

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

uuid_short 无符号自增长整形
唯一缺点就是作为默认值的话，需要 mysql8

主键用自增 id，业务用 random string 够用了，不放心的话入库前先查一下

UUID 插入性能太差了 高性能 MYSQL 中有案例当表数据增长 到 300 万行时 UUID 比自增慢了 4 倍 而且索引占用空间是自增的 1.7 倍 具体原因跟 22 楼说的一样

用 redis 写一个简单的带时间的自增 id 就好了

没特殊业务需求，一律自增。别的都是折腾

如果是只用自增，如何用最简单的方式避免暴露数据

非 C 端用自增就行了，C 端建议新项目伊始就用 Snowflake，不然后面体量大了想改就不容易了。UUID 方案如楼上所说没有任何优势所以就不要考虑了。

至于如何实现可靠的分布式 Snowflake 有很多轮子，推荐这款： https://github.com/Meituan-Dianping/Leaf

为什么要用 uuid 折磨自己。。如果小业务，那也随意把？但是自增 id 不香么

@Rocketer 想请教一下雪花算法生成的 id 做主键 性能是不是比递增主键性能差呢 存在数据页分裂情况吗

@honkki 单调递增的效果和自增是一模一样的，整体而言，因为少了一次读操作，代码的效率更高。