UUID v7 于 2024 年 5 月在 RFC 9562 中正式标准化，它的出现解决了 UUID v4 最显著的痛点：在数据库中作为主键时索引性能不佳。理解这两者之间的差异对于做出正确的架构决策至关重要。
UUID v4：纯粹的随机之美
UUID v4 使用 122 个随机比特加上 6 个固定比特（版本和变体位）来构造 UUID。这种设计简单优雅，完全不依赖于时间、机器标识或任何外部状态，使得任何系统在任何时刻都可以独立生成全局唯一的标识符。在不需要排序的场景中——比如会话 Token、文件去重标签、临时资源标识符——UUID v4 是完美的选择。
然而，这种随机性也有代价。当 UUID v4 被用作 B-tree 主键（PostgreSQL、MySQL InnoDB 等主流数据库的默认索引结构）时，随机插入导致新数据散落在整个索引树中，触发频繁的页面分裂和索引重组。数据库的写入性能在数据量增长时会显著下降，尤其是在机械磁盘上，因为随机 I/O 模式远比顺序 I/O 慢得多。这就是所谓的主键碎片化问题（Primary Key Fragmentation）。
UUID v7：时间为序的智慧
UUID v7 通过在 UUID 的开头放入一个 48 位的 Unix 毫秒级时间戳来解决碎片化问题。时间戳之后的剩余比特为随机填充。因为时间是单调递增的，新生成的 UUID v7 值在时间顺序上也大致递增（同一毫秒内可能有少许乱序），这正好匹配了 B-tree 索引对有序键的偏好。页面分裂大幅减少，索引树保持紧凑，写入性能比 UUID v4 显著提升，接近甚至在某些场景下达到与自增 ID 相媲美的水平。
UUID v7 的另一个优势是在应用程序层面也具有语义价值：你可以从 UUID 中提取出创建时间，而不需要额外的 created_at 列。这对于日志分析、事件溯源和调试都很有帮助。当然，这也意味着 UUID v7 会泄露生成时间——如果你出于隐私或安全考虑不希望暴露时间信息，UUID v4 会是更好的选择。
核心对比
UUID v4 不可排序，在数据库中作为主键时索引性能差，但不泄露任何信息，是真正匿名的全局唯一标识符。UUID v7 按时间排序，索引友好，与 B-tree 完美匹配，但以毫秒精度暴露了生成时间。两者都提供全球唯一性保证，无需要中央协调。两者都被 RFC 9562 正式标准化。
数据库索引性能详解
在 B-tree 索引中，所有叶子节点形成一条有序链表。当新数据的键是严格递增的（如自增 ID），所有插入都发生在最右边的叶子节点上，只需要简单的追加操作，几乎不会触发页面分裂和树平衡操作。当键是随机分布的（如 UUID v4），新数据会落在随机位置的页面中，导致频繁的页面分裂和大量的磁盘 I/O。UUID v7 通过时间戳前缀将值"限位"到一个大致有序的区间，使得写入集中在一个较小的范围内，大幅减少了页面分裂。
选择建议
如果你的项目使用 UUID v4，并且遇到了主键相关写入性能瓶颈，迁移到 UUID v7 是一个非常有价值的优化。对于新项目，如果数据库主键需要 UUID，那么直接将 UUID v7 作为默认选择，除非你明确不需要或不希望暴露时间信息。如果你完全不在数据库中重度使用 UUID 作为主键——仅仅将其作为分布式追踪 ID、会话 Token 或临时标识符——那么 UUID v4 仍然是一个简单且可靠的选择。
迁移路径
从 UUID v4 迁移到 v7 是一个渐进的过程。在相同的数据库列中，v4 和 v7 都可以共存，应用程序可以根据 UUID 的第 13 位半字节来判断版本。主键可以逐步从 v4 切换到 v7，只要冲突概率可以忽略，两者就可以混合。对于需要历史数据的 v4 值，通常不需要修改，只需将新记录的生成逻辑改为 v7 即可。
在实践中，使用我们的 UUID 生成器可以方便地测试和对比两个版本在不同使用场景下的表现。无论是批量生成 UUID v4 用于会话管理，还是批量生成 UUID v7 用于数据库主键测试，它都是最便捷的选择。
展望未来
UUID v7 源于社区对 UUID v4 局限性的广泛认识，特别是来自分布式数据库和云原生架构的需求。随着越来越多的数据库原生支持时间有序 ID（CockroachDB SERIAL、PostgreSQL 的扩展等），UUID v7 预期会逐渐成为 UUID 使用的默认最佳实践。未来的 UUID 版本（如正在提案中的 UUID v8）可能会进一步针对特定场景做出调整，但 v4 和 v7 的二分法——随机 vs 时间有序——仍会是 UUID 生态的核心框架。