UUID 还是自增 ID？分布式系统主键选型对比
自增 ID 有序高效但暴露规模、分库分表冲突；UUID 全局唯一但做主键伤索引。对比两者优劣与折中方案。
一、自增 ID 的优劣
优点：
- 有序插入，B+ 树追加写，性能好、缓存友好。
- 8 字节小，二级索引膨胀小。
缺点：
- 分库分表必冲突：多个实例各自从 1 数，全局不唯一。
- 泄露业务规模：订单号连续可猜，竞品能推算日单量；遍历攻击成本低。
二、UUID 的优劣
优点：
- 任意节点独立生成、全局唯一，天然分布式。
- 不可猜测、不泄露规模。
缺点：
- v4 随机无序：做 InnoDB 主键时页分裂、写放大明显。
- 16 字节 + 36 字符文本形式，索引与存储成本高。
三、折中方案盘点
- UUID v7：时间戳前缀大致有序，保住 UUID 优点同时缓解写放大——当前首选。
- 雪花算法 Snowflake：64 位 = 时间戳+机器ID+序列号，有序且短，但依赖时钟回拨处理。
- 号段模式/Leaf：数据库批量发号，中间件预取，兼顾有序与性能。
- 业务前缀+随机后缀（如订单号）：展示层可读，底层仍用上述主键。
四、选型建议
- 单库小系统：自增 ID 最省心。
- 多服务/多机房/分库：UUID v7 或雪花。
- 对外暴露的 ID：一律加不可猜测处理（雪花、随机短 ID），内部主键对外不可见。
在线体验
不用装任何环境，直接用本站UUID 生成器在线操作，数据都在浏览器本地处理，方便又安全。
常见问题
MySQL 主键用 UUID 一定慢吗？
v4 随机主键确实带来页分裂与缓存命中率下降，但「一定慢」言过其实——多数应用瓶颈不在这。追求极致写入或数据量巨大时换 v7/雪花即可。
雪花算法的时钟回拨是什么问题？
机器时间被 NTP 往回调时，可能生成重复 ID。常见处理：拒绝发号等待追平、用历史最大时间戳、备用位记录回拨次数——选实现时要确认这几点。
订单号为什么不直接用主键 ID？
泄露单量（竞品看末位差推算日单）、可被遍历爬取、无业务含义。订单号用「日期+业务前缀+随机段」独立生成，与内部主键解耦。