安德鲁·阿特金森：避免使用UUID版本4作为主键
💡
原文英文，约2900词，阅读约需11分钟。
📝
内容提要
在数据库中使用UUID版本4作为主键会导致性能下降和过多的IO，因为其随机生成的特性影响了索引的插入和检索效率。建议使用整数或时间排序的UUID（如UUID v7）来提高性能。
🎯
关键要点
- 在数据库中使用UUID版本4作为主键会导致性能下降和过多的IO。
- UUID版本4的随机生成特性影响了索引的插入和检索效率。
- 建议使用整数或时间排序的UUID（如UUID v7）来提高性能。
- UUID是Postgres中的原生数据类型，可以作为二进制数据存储。
- UUID版本4主要由随机位组成，缺乏自然排序。
- UUID版本7包含时间戳，更适合数据库索引。
- UUIDs在生成时可能会导致冲突，尤其是在微服务架构中。
- UUIDs的安全性常被误解，RFC指出它们不应被视为安全能力。
- UUIDs占用的存储空间较大，影响性能。
- UUID v4的随机性导致插入延迟和索引页分裂。
- 使用UUID v4时，查找操作的IO负担更重。
- 建议定期重建使用UUID的表和索引以减少碎片化。
- 对于新数据库，推荐使用整数和序列作为主键。
- UUID v7是UUID v4的替代方案，适合时间排序。
- UUID v4不适合用于需要快速查找的场景。
❓
延伸问答
为什么不建议在数据库中使用UUID版本4作为主键？
UUID版本4的随机生成特性导致性能下降和过多的IO，影响索引的插入和检索效率。
UUID版本7相比UUID版本4有什么优势？
UUID版本7包含时间戳，更适合数据库索引，能够提高插入和检索效率。
使用UUID作为主键的场景有哪些？
UUID适用于需要在客户端或多个服务中生成标识符的场景，特别是在微服务架构中。
UUID的存储空间占用情况如何？
UUID占用16字节（128位），是bigint（8字节）的两倍，影响性能。
如何减少使用UUID时的性能问题？
可以定期重建使用UUID的表和索引，以减少碎片化，并考虑使用UUID版本7。
UUID是否安全？
UUID不应被视为安全能力，RFC指出它们容易被猜测。
➡️
