为什么不推荐使用 UUID 作为主键

UUID 作为主键的讨论背景

• 面试官提出问题时，应提供具体场景，例如 UUID 是由日志服务器还是客户端生成。

UUID 的优点

1. 独立生成：可以在任何地方生成，无需与数据库服务器往返。
2. 简化逻辑：预先生成父表主键值，便于事务中同时插入父表和子表。

UUID 的缺点

1. 性能问题：索引更新开销较大，特别是在高并发情况下。
2. 存储空间：UUID（128位）相比整型主键需要更多存储空间。
3. 页分裂问题：数据写入速度超过一定阈值时，性能下降明显。

性能与存储效率对比

• 在数据量较大时，UUID 的插入效率较低，特别是在后续数据增长时性能下降更快。
• 效率排名：自增键（auto_key）> 随机键（random_key）> UUID。

技术实现与建议

1. InnoDB 存储引擎：建议按主键的自增顺序插入，使用单调增加的聚簇键值。
2. UUID 的特性：虽然不稠密，但页分裂带来的性能损耗在 SSD 时代有所下降。

UUID 与其他方案的比较

1. 雪花算法（Snowflake）：提供有效期，适用于分布式系统。
2. UUID 变体：如前64位存储时间的雪花版 UUID，确保有序性。

综合考虑

• UUID 的优点包括极低的冲突概率、对并库和拆库友好、存储开销并非不可接受。
• 缺点与优点的取舍取决于具体应用场景，如 SSD 的高读写速度可能降低页分裂的影响。

实际应用中的折中方案

• 有些做法是设置自增 ID 但不使用，同时保留 UUID 并建立索引，用于查询。

结论

• 是否使用 UUID 作为主键应根据具体业务需求、系统架构和性能要求综合评估。