UUID 作为主键的讨论背景
- 面试官提出问题时,应提供具体场景,例如 UUID 是由日志服务器还是客户端生成。
UUID 的优点
- 独立生成:可以在任何地方生成,无需与数据库服务器往返。
- 简化逻辑:预先生成父表主键值,便于事务中同时插入父表和子表。
UUID 的缺点
- 性能问题:索引更新开销较大,特别是在高并发情况下。
- 存储空间:UUID(128位)相比整型主键需要更多存储空间。
- 页分裂问题:数据写入速度超过一定阈值时,性能下降明显。
性能与存储效率对比
- 在数据量较大时,UUID 的插入效率较低,特别是在后续数据增长时性能下降更快。
- 效率排名:自增键(auto_key)> 随机键(random_key)> UUID。
技术实现与建议
- InnoDB 存储引擎:建议按主键的自增顺序插入,使用单调增加的聚簇键值。
- UUID 的特性:虽然不稠密,但页分裂带来的性能损耗在 SSD 时代有所下降。
UUID 与其他方案的比较
- 雪花算法(Snowflake):提供有效期,适用于分布式系统。
- UUID 变体:如前64位存储时间的雪花版 UUID,确保有序性。
综合考虑
- UUID 的优点包括极低的冲突概率、对并库和拆库友好、存储开销并非不可接受。
- 缺点与优点的取舍取决于具体应用场景,如 SSD 的高读写速度可能降低页分裂的影响。
实际应用中的折中方案
- 有些做法是设置自增 ID 但不使用,同时保留 UUID 并建立索引,用于查询。
结论
- 是否使用 UUID 作为主键应根据具体业务需求、系统架构和性能要求综合评估。