UUID v4 vs v7：数据库性能、索引与现代应用

什么是 UUID？

UUID（通用唯一标识符）是一个 128 位标签，用于在分布式系统中无需中央协调即可唯一标识信息。 UUID 通常以 36 字符字符串呈现，格式为 xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx，其中 M 半字节编码版本，N 编码变体。UUID 格式最初由 RFC 4122 正式定义，现由 RFC 9562 规范，后者新增了有序变体。

UUID 是分布式应用、事件溯源系统以及任何需要离线或跨节点生成标识符的服务的首选主键。其 128 位宽度使意外碰撞几乎不可能，但正如我们将看到的，并非所有 UUID 版本在数据库索引中的行为都相同。

UUID v4 的工作方式

UUID 版本 4 定义于 RFC 4122，对不被版本和变体字段固定的全部 122 位使用密码学安全的随机数。每个生成的 UUID v4 与其他任何 UUID v4 统计独立，这保证了唯一性，但产生的值在整个 128 位空间中均匀分布。

这种随机性对唯一性极佳，但正是它使 UUID v4 对数据库引擎代价高昂。因为每个新值可能落在已排序索引的任意位置，数据库无法预测下一次插入将去向何处，从而破坏了所有依赖顺序访问的优化。

UUID v7 的工作方式（RFC 9562）

UUID v7 引入时间戳排序，在最高有效位嵌入 48 位 Unix 纪元时间戳（毫秒级），其后是 4 位版本号和 74 位随机性。 由于时间戳占据高位，两个按时间顺序生成的 UUID 在字节层面也会按时间顺序排序。UUID v7 定义于 RFC 9562，专为修复 UUID v4 的数据库性能问题而设计，同时保持线格式兼容——它仍是存储在同一列类型中的 128 位 UUID。

RFC 9562 将 UUID 版本 7 定义为时间有序标识符，其值在单个节点内单调递增，使其非常适合作为数据库主键。 74 位随机位保证即使同一毫秒内生成数百万个 UUID 也保持唯一，而前导时间戳确保索引看到的是稳定、以追加为主的新键流，而非随机散布。

数据库索引性能分析

数据库性能基准测试显示，从 UUID v4 切换到 UUID v7 可将大表的插入吞吐量提升 2–4 倍，因为有序插入使活跃索引页保持热状态，避免了破坏缓冲池的随机 I/O 模式。 当插入 UUID v4 值时，B-tree 索引必须为每一行不断寻道到随机叶子页。在高并发下，这导致缓存未命中、锁竞争以及频繁的页分裂，使索引碎片化。

使用 UUID v7 时，连续插入几乎总是指向索引最右侧的叶子页，该页驻留在内存中。结果是顺序 I/O、更小的写放大以及随时间显著降低的碎片化。在实践中，增长超过数千万行的表收益最大——这恰恰是 UUID v4 开始非线性退化的区间。

B-tree 局部性解释

B-tree 索引局部性显著影响写入吞吐量和存储效率，因为 B-tree 仅在叶子页填满时才通过分裂来维护其不变量——而随机插入是均匀填充而非顺序填充。 使用 UUID v4 时，每次插入都是随机探测：引擎从根遍历到均匀随机选取的叶子页，写入其中，并可能引发分裂向上层联。随时间推移，索引变成半满页的拼凑。

UUID v7 完全改变了这一图景。因为新值大于（几乎）所有现有值，它们集中在最右侧叶子页。当该页填满时，它分裂一次，新的最右侧页成为活跃追加目标，索引的其余部分从不被触及。这种以追加为主的行为使页填充因子保持高位，减小索引在磁盘上的体积，并让数据库预取下一个顺序页——这是随机 UUID v4 插入无法实现的。

迁移注意事项

将现有系统从 UUID v4 迁移到 UUID v7 不需要重写已存储的值。由于两个版本共享相同的 128 位布局和相同的列类型（如 PostgreSQL 的 UUID、MySQL 的 BINARY(16)），最简单的迁移方式是：

• ✓切换默认值：将主键的默认生成方式切换为 UUID v7，适用于所有新行。
• ✓保留现有 v4 值不变——它们仍然有效，并在其自身范围内继续正确排序。
• ✓在维护窗口重建索引以回收因 v4 碎片化丢失的空间，然后让 v7 保持其紧凑。
• ✓审计外部引用——任何解析版本半字节的系统现在都会同时看到 4 和 7，这是设计如此。

避免原地重写旧 v4 值的诱惑：这会破坏任何存储了原始标识符的外部系统，且没有任何实际好处，因为 v4 值与 v7 并存时仍能正确工作。

对比表：UUID v4 vs v7

常见问题

相关工具