我想的是一个表有两个基本字段 id 和 primary_key，id 是自增，且为主键； primary_key 为 UUID，是逻辑主键，表与表之间通过 primary_key 来关联，对前端也只暴露 primary_key 。
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 1932 days ago, the information mentioned may be changed or developed.
31 replies • 2021-08-01 06:14:22 +08:00
 |
jenlorsJul 30, 2021
1
自增效率最高，UUID 不会暴露数据量，但是效率低，看业务场景吧
|
 |
ThanksSirAlexJul 30, 2021
2
用 UUID 你要自己有一个能竟然范围查找和排序的字段，雪花算法是分布式自增 id，如果你是单机，就不需要考虑这个东西
|
 |
CodeCodeStudyJul 30, 2021
3
数据量不大就不要用雪花算法了，那是给分布式搞的，数字太大，看着头疼
|
 |
2kCS5c0b0ITXE5k2Jul 30, 2021
4
表和表直接直接用主键不也可以吗. 你对外不暴露就行了.
|
 |
xwaywayJul 30, 2021
5
我们现在一般是自增主键做 id，业务上设置个唯一键
|
 |
RRRogerJul 30, 2021
6
postgres integer 最大是 2^31-1
不知道 MySQL 有没有这样的问题 |
 |
AquanllRJul 30, 2021
8
雪花算法 ID，可以兼容后期分布式架构，但是限制了 1024 个`workerID`，可以按自己业务架构定向去使用哪种方案，小项目单体自增完全 ok 。
|
 |
LemengJul 30, 2021
10
做的自增
|
 |
joesonwJul 30, 2021
11
不想暴露数据量, 数据在后端 hashid 一下就好. 雪花不允许服务器时间有回滚的, 实施起来难度也不小.
|
 |
wei745359223Jul 30, 2021
12
可以用 hashid 相互转换自增 ID
|
 |
potatowishJul 30, 2021 via iPhone
13
数据表当然是存原始数据，敏感数据 hash 一下再对外暴露
|
 |
caixiaomaoJul 30, 2021
14
用自增 id 比较多
|
 |
15
mysql 主键 clustered index 用 uuid 简直是灾难
|
1 |
NumbcoderJul 30, 2021
16
UUID 这种垃圾还有人用吗，既不能防碰撞，又是无序，还占空间。
生成唯一 ID 的方式那么多，再不济自己根据业务需求加随机数生成的 ID 也比 UUID 好啊 |
|
aragakiyuiiJul 30, 2021 via iPhone
17
@Numbcoder uuid 优势就是简单😂不过还是得分数据库，postgres 支持 uuid 类型，用 16 字节存储 binary 数据。不是聚簇索引效率不会很差，肯定比不过自增 id 就是了
|
 |
xuanbgJul 30, 2021
18
自增最大的问题是想要知道 id 还要读一次。。。uuid 和雪花就没这毛病。不过 uuid 虽然简单，但是不利于索引。
so，还是雪花好了，写个雪花 id 生成器没几行代码。 |
 |
RocketerJul 31, 2021
19
千万别用 uuid，这玩意效率不高，暗坑不少。
比如版本问题，你如果用多种数据库（比如 SQL Server 和 MongoDB ），你会发现他们默认的 uuid 版本不一样，不专门设置一下就无法愉快地一起玩耍。 我现在都用雪花算法，直接用来做主键就好了，无须再多一个 primary_key 。 |
 |
jorneyrJul 31, 2021
20
我喜欢用雪花，因为在业务层未插入到数据库的时候就可以生成好 ID，尤其是同一个业务中要处理多个用 ID 关联的对象，业务层可以把他们依赖的 ID 生成好直接使用，处理好关系后用事务保存到数据库。如果用自增 ID，得按照先后顺序保存到数据库并且查询得到最新的 ID，然后再处理关系，比雪花麻烦一些，业务逻辑写起来也麻烦。
|
 |
NXzCH8fP20468ML5Jul 31, 2021 via Android
21
uuid_short 无符号自增长整形
唯一缺点就是作为默认值的话，需要 mysql8 |
 |
offswitchJul 31, 2021
22
uuid 不要用，聚集索引有序，会引起频繁页分裂和页合并。
|
 |
liuzhaowei55Jul 31, 2021 via iPhone
23
主键用自增 id，业务用 random string 够用了，不放心的话入库前先查一下
|
 |
OssiJul 31, 2021
24
UUID 插入性能太差了 高性能 MYSQL 中有案例当表数据增长 到 300 万行时 UUID 比自增慢了 4 倍 而且索引占用空间是自增的 1.7 倍 具体原因跟 22 楼说的一样
|
 |
simple2025Jul 31, 2021
25
用 redis 写一个简单的带时间的自增 id 就好了
|
 |
hushaoJul 31, 2021 via iPhone
26
没特殊业务需求，一律自增。别的都是折腾
|
 |
charlie21Jul 31, 2021
27
如果是只用自增，如何用最简单的方式避免暴露数据
|
 |
mreasonyangJul 31, 2021 via iPhone
28
非 C 端用自增就行了，C 端建议新项目伊始就用 Snowflake，不然后面体量大了想改就不容易了。UUID 方案如楼上所说没有任何优势所以就不要考虑了。
至于如何实现可靠的分布式 Snowflake 有很多轮子，推荐这款： https://github.com/Meituan-Dianping/Leaf |
 |
vanityfairnJul 31, 2021
29
为什么要用 uuid 折磨自己。。如果小业务，那也随意把？但是自增 id 不香么
|
Select Language