UUID v4 与 v7：同样是唯一 ID，为什么数据库表现可能完全不同？

UUID（Universally Unique Identifier）是 128 位的全局唯一标识符。它的价值在于：不依赖数据库自增列、不依赖中心化 ID 服务，应用或多个分布式节点都可以自行生成 ID。

但 UUID 不是只有一种生成方式。对于数据库主键、唯一索引和持续写入场景，最常见也最值得理解的是 UUID v4 与 UUID v7。

01 | 先说结论

• UUID v4：随机型 UUID，唯一性高，但插入 B-tree 索引的位置随机。
• UUID v7：时间有序 UUID，唯一性高，并且新生成的值大致随时间递增，更适合持续插入的数据库主键。
• 如果只在单个 Oracle 数据库内生成 ID，NUMBER + IDENTITY / SEQUENCE 往往仍是最简单、最节省索引空间的选择。
• 如果需要应用侧生成、跨服务生成或离线生成 UUID，优先考虑 UUID v7，而不是随机 UUID v4。

UUID v4 和 v7 都是 IETF UUID 标准的一部分。v4 使用随机数据；v7 的前 48 位保存 Unix 毫秒时间戳，其余部分用于版本标识、变体标识和随机性。

02 | UUID v4：随机且无序

UUID v4 的主要来源是随机数，一个典型的 v4 示例（来自 RFC 4122 文档）如下：

550e8400-e29b-41d4-a716-446655440000

这种随机性带来一个数据库层面的问题：当 UUID v4 作为主键插入 B-tree 索引时，新记录会落在索引的随机位置。随着数据量增长，索引页频繁分裂、随机 I/O 增多，持续写入场景下的性能可能明显下降。

03 | UUID v7：时间有序

UUID v7 的设计思路不同。它的前 48 位直接取自 Unix 毫秒时间戳，因此新生成的 UUID 大致随时间递增。插入 B-tree 索引时，新记录更倾向于追加到索引末尾附近，减少了页分裂和随机写入，对持续插入更友好。

同时，UUID v7 仍然保留了足够的随机位，唯一性并不依赖单一时间戳，分布式节点各自生成也不会冲突。

04 | 如何选择

如果 ID 只在单个数据库内部生成，使用 NUMBER + IDENTITY / SEQUENCE 通常最简单，索引占用也最小。但如果业务需要在应用侧、跨服务或离线环境生成 ID，UUID v7 是比 v4 更合适的主键选择——它既保留了 UUID 的全局唯一性，又避免了随机插入带来的索引性能损耗。

关注我，和AI一起成长~