Josef Machytka：深入探讨PostgreSQL 18中的旧UUIDv4与新UUIDv7
💡
原文英文，约2900词，阅读约需11分钟。
📝
内容提要
UUID作为PostgreSQL主键的使用引发讨论。UUIDv4完全随机，导致索引碎片化和随机I/O，而UUIDv7引入时间戳，显著改善了索引性能和物理布局，适合大规模数据应用。
🎯
关键要点
- UUID作为PostgreSQL主键的使用引发讨论，UUIDv4完全随机导致索引碎片化和随机I/O。
- UUIDv7引入时间戳，显著改善了索引性能和物理布局，适合大规模数据应用。
- UUID是128位的唯一标识符，具有极大的组合可能性，几乎不可能出现重复。
- PostgreSQL 18引入了对UUIDv7的原生支持，UUIDv7生成的值是时间有序的。
- UUIDv4的随机性导致频繁的B树页面分裂和高度碎片化的主键索引。
- UUIDv7的插入速度显著快于UUIDv4，尤其是在处理大量数据时。
- UUIDv4的索引结构高度碎片化，而UUIDv7的索引结构则更为紧凑和连续。
- UUIDv7的引入使得PostgreSQL在保持UUID的唯一性和分布式生成优势的同时，改善了索引行为。
- UUIDv7嵌入了创建时间戳，可能会泄露近似的创建时间，但在大多数情况下是可接受的。
- UUIDv7在性能和物理布局上显著优于UUIDv4，适合替代传统的BIGINT主键。
❓
延伸问答
UUIDv4和UUIDv7在PostgreSQL中的主要区别是什么？
UUIDv4是完全随机的，导致索引碎片化和随机I/O，而UUIDv7引入时间戳，改善了索引性能和物理布局。
为什么UUIDv7在处理大规模数据时更适合？
UUIDv7的插入速度显著快于UUIDv4，且其索引结构更为紧凑和连续，适合大规模数据应用。
PostgreSQL 18中如何生成UUIDv7？
在PostgreSQL 18中，可以使用uuidv7()函数生成UUIDv7。
UUIDv4的随机性对数据库性能有什么影响？
UUIDv4的随机性导致频繁的B树页面分裂和高度碎片化的主键索引，增加了随机I/O。
UUIDv7的时间戳特性有什么潜在风险？
UUIDv7嵌入的时间戳可能会泄露近似的创建时间，但在大多数情况下是可接受的。
使用UUID作为主键的优势是什么？
UUID提供了极大的唯一性，几乎不可能出现重复，适合需要分布式生成的应用场景。
🏷️
标签
➡️
