Loading...
Loading...
免费的在线 UUID v4 生成器——单个或批量生成 UUID，用于数据库主键、会话令牌和 API 资源。一键全部复制。
UUID（通用唯一标识符）是一种由 RFC 4122 标准化的 128 位标识符。UUID 设计为在空间和时间上全球唯一，无需中央注册机构。它们已成为数据库主键、API 资源标识符、分布式系统 ID 以及任何需要在不同系统间独立生成 ID 且不发生冲突的场景的标准选择。
UUID v4 是最常见的变体，使用随机数生成所有 128 位（除 6 位用于标识版本和变体外）。这提供了约 2^122 个可能值——约 5.3 × 10^36 种组合——使得碰撞概率天文学般地低。你可以每秒生成 10 亿个 UUID 持续 85 年，才达到 50% 的碰撞概率。
其他 UUID 版本服务于不同目的：UUID v1 使用时间戳 + MAC 地址（可追溯到特定机器），UUID v3/v5 使用基于命名空间的确定性生成（相同输入 = 相同 UUID），UUID v7（提案中）将时间戳前缀编码以实现数据库索引友好的有序性。对于大多数应用，UUID v4 是正确的默认选择。
UUID 的常见用途包括：数据库主键（避免分布式数据库中的自增冲突）、API 资源标识符（不可预测、非顺序）、会话和事务 ID、跨微服务的事件追踪，以及日志系统中的关联 ID。UUID 在微服务和离线优先应用中特别有价值——这些场景下 ID 必须在无中央服务器的情况下生成。
性能考虑：UUID v4 主键因其随机性会导致数据库索引碎片化。UUID v7 或 ULID 通过先编码时间分量来解决此问题。UUID 作为字符串长度为 36 字符（128 位 = 16 字节二进制）。为获得最佳性能，建议以 binary(16) 存储或使用 PostgreSQL 的原生 uuid 类型。
UUID 在事件溯源和 CQRS 架构中越来越常用——每个状态变更都作为具有唯一标识符的事件记录。在这些模式中，UUID 允许事件在多个服务中独立生成，随后可无冲突地合并。这使得它们成为离线优先应用、物联网设备网络以及任何在 ID 生成时无法保证网络连接的系统的理想选择。
不保证，但碰撞概率可忽略不计。UUID v4 有 122 个随机位——约 5.3 × 10^36 个可能值。生成 10 亿个 UUID 后的碰撞概率约为 10^18 分之一。实际使用中可视为唯一。
UUID v4 完全随机。UUID v7 将毫秒精度的时间戳编码为前缀，使 UUID 可排序并能减少数据库索引碎片。UUID v7 正成为新应用的推荐选择。
UUID 更适合分布式系统、防止 ID 枚举、可客户端生成。自增 ID 更快（整数索引）、存储更小、可读性更高、调试更方便。需要全局唯一性或防 ID 猜测时选择 UUID。
可以，但需注意性能影响。UUID v4 值是随机的，会导致 B 树索引碎片化。解决方案包括使用 UUID v7（按时间排序）、重新排列 UUID 字节以实现顺序性，或使用单独的自增整数作为聚集索引、UUID 作为辅助索引。PostgreSQL 的原生 uuid 类型比 MySQL 更高效地处理 UUID。
空 UUID 是全零——00000000-0000-0000-0000-000000000000。它表示没有 ID，在数据库和 API 中用作标记值。可以作为可选外键的默认值，或表示未初始化或已删除的记录。标准建议在业务逻辑中尽量避免使用空 UUID。