UUID v1/v4/v7 有什么区别?数据库主键该用哪个版本
UUID v4 纯随机 122 位,v7 时间戳前缀可排序。讲清各版本原理、索引碎片化问题与选型建议,附在线 UUID 生成工具。
一、UUID 是什么
UUID(通用唯一标识符)是 128 位的标识符,标准格式为 32 个 Hex 字符分 5 段:550e8400-e29b-41d4-a716-446655440000。理论组合数约 3.4 × 1038,随机生成 collision 概率低到可以忽略。
版本号藏在第 3 段的首位(如 41d4 表示 v4),variant 藏在第 4 段首位(8/9/a/b 开头)。
二、v1:基于 MAC 地址和时间
UUID v1 由「时间戳 + 机器 MAC 地址」生成,优点是趋势有序,缺点是泄露物理地址、多节点时钟同步麻烦。出于隐私考虑,现代应用基本不用 v1。
三、v4:纯随机,最常用
v4 是目前使用最广的版本:除版本和 variant 之外的 122 位全部随机。它不依赖任何环境,生成简单、不泄露信息。
但 v4 有个工程痛点:完全无序。作为 MySQL InnoDB 主键时,随机插入导致 B+ 树频繁页分裂、缓存命中率下降,写入性能比自增 ID 差不少。
四、v7:时间戳前缀,新宠儿
UUID v7(RFC 9562 正式标准化)把毫秒级 Unix 时间戳放在最高 48 位,其余随机:
- 大致按时间递增,做主键时索引友好,缓解页分裂。
- 不泄露 MAC 地址,隐私安全。
- 按创建时间排序需求可以直接用主键排序,省掉额外时间字段。
新项目的主键选型,v7 是当前社区推荐答案。
在线体验
不用装任何环境,直接用本站UUID 生成器在线操作,数据都在浏览器本地处理,方便又安全。
常见问题
UUID 会不会重复?
v4 的重复概率小到可以忽略:生成 10 亿个 UUID 后出现一次碰撞的概率约为 10 亿分之 0.00000006。日常规模完全不用担心。
UUID 主键比自增 ID 慢吗?
v4 主键因为随机写入确实会慢一些(页分裂、索引膨胀);v7 有序后差距大幅缩小。同时 UUID 带来分布式唯一、防遍历的好处,要综合权衡。
UUID 的 8-4-4-4-12 格式能变短吗?
可以用 Base64 编码 16 字节,缩短到 22 个字符(URL Safe 版),诸如 nanoid、ULID 也是流行的短 ID 方案。
