MySQL 主键用自增好还是 UUID、雪花算法 ID 好？用自增+UUID 会不会好一点？
polyang · 2021-07-30 15:14:25 +08:00 · 6644 次点击这是一个创建于 1203 天前的主题，其中的信息可能已经有所发展或是发生改变。
我想的是一个表有两个基本字段 id 和 primary_key，id 是自增，且为主键； primary_key 为 UUID，是逻辑主键，表与表之间通过 primary_key 来关联，对前端也只暴露 primary_key 。
31 条回复 • 2021-08-01 06:14:22 +08:00
 |
1
jenlors 2021-07-30 15:23:11 +08:00
自增效率最高，UUID 不会暴露数据量，但是效率低，看业务场景吧
|
 |
2
ThanksSirAlex 2021-07-30 15:38:24 +08:00
用 UUID 你要自己有一个能竟然范围查找和排序的字段，雪花算法是分布式自增 id，如果你是单机，就不需要考虑这个东西
|
 |
3
CodeCodeStudy 2021-07-30 16:23:34 +08:00
数据量不大就不要用雪花算法了，那是给分布式搞的，数字太大，看着头疼
|
 |
4
2kCS5c0b0ITXE5k2 2021-07-30 16:25:55 +08:00
表和表直接直接用主键不也可以吗. 你对外不暴露就行了.
|
 |
5
xwayway 2021-07-30 16:29:42 +08:00
我们现在一般是自增主键做 id，业务上设置个唯一键
|
 |
6
RRRoger 2021-07-30 16:31:57 +08:00
postgres integer 最大是 2^31-1
不知道 MySQL 有没有这样的问题 |
 |
8
AquanllR 2021-07-30 16:42:30 +08:00
雪花算法 ID，可以兼容后期分布式架构，但是限制了 1024 个`workerID`，可以按自己业务架构定向去使用哪种方案，小项目单体自增完全 ok 。
|
 |
10
Lemeng 2021-07-30 17:11:30 +08:00
做的自增
|
 |
11
joesonw 2021-07-30 17:13:14 +08:00
不想暴露数据量, 数据在后端 hashid 一下就好. 雪花不允许服务器时间有回滚的, 实施起来难度也不小.
|
 |
12
wei745359223 2021-07-30 17:14:24 +08:00
可以用 hashid 相互转换自增 ID
|
 |
13
potatowish 2021-07-30 17:19:17 +08:00 via iPhone
数据表当然是存原始数据，敏感数据 hash 一下再对外暴露
|
 |
14
caixiaomao 2021-07-30 17:32:15 +08:00
用自增 id 比较多
|
 |
15
aragakiyuii 2021-07-30 17:38:50 +08:00 via iPhone  1
mysql 主键 clustered index 用 uuid 简直是灾难
|
 |
16
Numbcoder 2021-07-30 17:54:27 +08:00
UUID 这种垃圾还有人用吗，既不能防碰撞，又是无序，还占空间。
生成唯一 ID 的方式那么多，再不济自己根据业务需求加随机数生成的 ID 也比 UUID 好啊 |
|
17
aragakiyuii 2021-07-30 19:21:01 +08:00 via iPhone
@Numbcoder uuid 优势就是简单😂不过还是得分数据库，postgres 支持 uuid 类型，用 16 字节存储 binary 数据。不是聚簇索引效率不会很差，肯定比不过自增 id 就是了
|
 |
18
xuanbg 2021-07-30 20:11:11 +08:00
自增最大的问题是想要知道 id 还要读一次。。。uuid 和雪花就没这毛病。不过 uuid 虽然简单，但是不利于索引。
so，还是雪花好了，写个雪花 id 生成器没几行代码。 |
 |
19
Rocketer 2021-07-31 01:07:29 +08:00
千万别用 uuid，这玩意效率不高，暗坑不少。
比如版本问题，你如果用多种数据库（比如 SQL Server 和 MongoDB ），你会发现他们默认的 uuid 版本不一样，不专门设置一下就无法愉快地一起玩耍。 我现在都用雪花算法，直接用来做主键就好了，无须再多一个 primary_key 。 |
 |
20
jorneyr 2021-07-31 08:14:28 +08:00
我喜欢用雪花，因为在业务层未插入到数据库的时候就可以生成好 ID，尤其是同一个业务中要处理多个用 ID 关联的对象，业务层可以把他们依赖的 ID 生成好直接使用，处理好关系后用事务保存到数据库。如果用自增 ID，得按照先后顺序保存到数据库并且查询得到最新的 ID，然后再处理关系，比雪花麻烦一些，业务逻辑写起来也麻烦。
|
 |
21
NXzCH8fP20468ML5 2021-07-31 08:53:18 +08:00 via Android
uuid_short 无符号自增长整形
唯一缺点就是作为默认值的话，需要 mysql8 |
 |
22
offswitch 2021-07-31 08:59:08 +08:00
uuid 不要用，聚集索引有序，会引起频繁页分裂和页合并。
|
 |
23
liuzhaowei55 2021-07-31 09:42:44 +08:00 via iPhone
主键用自增 id，业务用 random string 够用了，不放心的话入库前先查一下
|
 |
24
Verizon 2021-07-31 10:23:26 +08:00
UUID 插入性能太差了 高性能 MYSQL 中有案例当表数据增长 到 300 万行时 UUID 比自增慢了 4 倍 而且索引占用空间是自增的 1.7 倍 具体原因跟 22 楼说的一样
|
 |
25
chenqh 2021-07-31 14:02:40 +08:00
用 redis 写一个简单的带时间的自增 id 就好了
|
 |
26
hushao 2021-07-31 14:12:26 +08:00 via iPhone
没特殊业务需求，一律自增。别的都是折腾
|
 |
27
charlie21 2021-07-31 14:15:57 +08:00
如果是只用自增，如何用最简单的方式避免暴露数据
|
 |
28
mreasonyang 2021-07-31 14:31:35 +08:00 via iPhone
非 C 端用自增就行了，C 端建议新项目伊始就用 Snowflake，不然后面体量大了想改就不容易了。UUID 方案如楼上所说没有任何优势所以就不要考虑了。
至于如何实现可靠的分布式 Snowflake 有很多轮子，推荐这款： https://github.com/Meituan-Dianping/Leaf |
 |
29
vanityfairn 2021-07-31 15:00:52 +08:00
为什么要用 uuid 折磨自己。。如果小业务，那也随意把？但是自增 id 不香么
|
Select Language