UUID Generator

什么是 UUID？

UUID（Universally Unique Identifier，RFC 4122 / RFC 9562）是 128 位标识符，无需中央分配机构即可创建，并在全球范围内实际唯一。文本形式为 32 个十六进制字符，按 `8-4-4-4-12` 用连字符分为五段，含分隔符共 36 字符。

存在多个版本。v1 使用时间 + MAC 地址（隐私问题）；v3 与 v5 由 namespace + name 推导（确定性）；v4 完全随机（现代默认）；v7 按时间排序，解决 v4 在数据库索引中的问题。

此外，ULID 与 NanoID 是流行的非 IETF 备选。ULID 是 26 字符可排序字符串，NanoID 是简短 URL 安全 ID（常为 21 字符）。具体选哪种主要看存储与 URL 布局。

v4 与 v7 与 ULID 与 NanoID

四种最重要变体的快速对比：

Crockford base32（ULID）省略了 I、L、O、U，避免与 1、0、V 混淆。

什么时候用哪种？

实际工作中的经验法则：

• UUID v4：非排序 ID 的稳妥默认（Session、幂等键、关联 ID）。122 位熵，碰撞概率极低。
• UUID v7：推荐用作数据库主键。前 48 位是 unix-ms 时间戳，新行总写到 B-Tree 索引尾部（页分裂压力低、局部性好）。
• ULID：需要时间排序且在 URL 与日志中易读时使用。26 字符，比 UUID 短，但不是 RFC 标准，部分工具栈缺乏原生支持。
• NanoID-21：面向用户的分享链接和 slug 的理想选择。21 字符、URL 安全，约 126 位熵（比 UUID v4 更安全）且更短。

为什么生产环境不用自增 ID？

自增 ID（例如 `BIGINT IDENTITY` 或 `SERIAL`）简单、快、索引友好，但不满足若干现代需求：

• 泄露业务指标：竞争对手看到两个连续订单号就能粗略推算每日订单量。
• 无法防爬：`/users/123` 是任何暴破爬虫都会从 1 走到 n 的对象，每个 ID 都可枚举。
• 阻碍分布式系统：多区域部署或离线客户端（移动端、边缘）需协调序列或运行中央 ID 服务。UUID 完全避免这点。
• 无法客户端预分配：前端在 INSERT 之前无法预定一个自增 ID（例如乐观 UI）。UUID 在客户端生成后随 INSERT 一起传递。
• 不利于测试：回滚数据的测试会与 sequence 冲突或留空洞。UUID 在测试中保持稳定。

建议：纯运维表（迁移日志、计数器）继续用自增 ID；领域实体（User、Order、Document）默认主键用 UUID v7。

UUID 在数据库中的性能

对 UUID 最常见的反对声音是 "会破坏索引性能"。这部分曾是真的，但要么容易解决，要么用 v7/ULID 完全规避。

真正问题不在体积（16 字节 vs bigint 8 字节），而在随机插入顺序：用 v4 时每次插入都落在 B-Tree 中段某处，造成页分裂、缓存冷却与写放大。

• 方案 1：用 UUID v7 或 ULID 取代 v4。时间排序的位段保证新行写入索引尾部。
• 方案 2：在 PostgreSQL 用 `uuid` 类型，在 MySQL 用 `BINARY(16)`（替代 `CHAR(36)`），每行省 20 字节，并让比较达到整数级速度。
• 方案 3：把聚簇索引建在另一个键（例如单调递增）上，UUID 作为二级键。在 MS SQL Server 中常见。
• 方案 4：批量插入时按排序顺序插入，或使用最后重建索引的批量加载器。

在新版本 Postgres 与 MySQL 上，UUID v7 作为主键在几乎所有负载下都比 v4 更快，并与 bigint 自增大致相当，同时保留所有优势（不泄露、可分布式生成、可客户端生成）。

在 KernelHost 部署高吞吐后端

如果你每天在数据库中存储数百万 UUID，需要 NVMe 存储、ECC 内存和稳定网络。KernelHost 在 Frankfurt FRA01 自营独立服务器与 VPS，含 DDoS 防护、IPv4 + IPv6 与 1 Gbit/s。对德国和奥地利客户低 RTT，价格合理。公司位于 Wien（AT），数据中心在 Frankfurt（DE）。

UUID 常见问题