UUID生成器 - 在线批量生成UUID/GUID

UUID V4 生成器

生成数量 (1-100)

大写无连字符

📖 UUID 通用唯一标识符深度指南

UUID（Universally Unique Identifier，通用唯一标识符）是一个128位的标识符，由开放软件基金会（OSF）在分布式计算环境（DCE）规范中首次定义，后被IETF标准化为RFC 4122，并在2024年更新为RFC 9562。UUID的核心设计理念是：在不需要中央注册机构的情况下，任何人在任何时间、任何地点都能生成一个全球唯一的标识符。这一特性使UUID成为分布式系统、微服务架构和数据库设计中不可或缺的基础组件。

UUID vs GUID：有什么区别？

GUID（Globally Unique Identifier，全局唯一标识符）是微软对UUID的称呼。从技术角度来说，GUID和UUID是完全相同的东西——都是128位标识符，使用相同的格式和生成算法。微软在COM、.NET、SQL Server等技术中使用"GUID"这个名称，而其他平台（Linux、Java、Python、Web标准等）通常使用"UUID"。唯一的细微差异是微软在某些场景下会使用大括号包裹GUID，如 {550e8400-e29b-41d4-a716-446655440000}，但这只是显示格式的区别。

UUID 格式解剖

标准格式（RFC 4122）：
xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

总长度：36个字符（含4个连字符）= 32个十六进制数字
存储大小：128位 = 16字节

各段含义：
| 时间低位(8) | 时间中位(4) | 版本+时间高位(4) | 变体+序列(4) | 节点标识(12) |

M = 版本号（1-8），位于第13个十六进制字符
N = 变体标识，取值为 8/9/a/b，位于第17个十六进制字符

以UUID v4为例：
550e8400-e29b-41d4-a716-446655440000
^版本=4 ^变体=a (RFC 4122)

各版本的M值：v1=1, v2=2, v3=3, v4=4, v5=5, v6=6, v7=7, v8=8

UUID 各版本详解与选择指南

版本	生成方式	确定性	可排序	隐私安全	推荐场景
v1	时间戳(60位) + MAC地址	否	部分	差（泄露MAC和时间）	内部系统、不暴露给外部
v2	时间戳 + POSIX UID/GID	否	部分	差	DCE安全场景（极少使用）
v3	命名空间 + 名称的MD5哈希	是	否	好	根据名称生成固定UUID（如URL映射）
v4	122位密码学安全随机数	否	否	最好	最通用，适合绝大多数场景
v5	命名空间 + 名称的SHA-1哈希	是	否	好	类似v3但更安全，优先于v3使用
v6	v1改进，时间戳重排列	否	是	差	需要时间排序的旧系统迁移
v7	Unix毫秒时间戳 + 随机数	否	是	较好	数据库主键（强烈推荐）
v8	自定义格式（保留版本/变体位）	取决于实现	取决于实现	取决于实现	有特殊需求的自定义方案

碰撞概率的数学分析

UUID v4拥有122位有效随机位，总共有2^122 ≈ 5.3 × 10^36种可能的值。根据生日悖论（Birthday Paradox），当生成的UUID数量达到约2.71 × 10^18个时，碰撞概率才达到50%。为了直观理解这个数字的含义：

场景	已生成UUID数量	碰撞概率	直观比较
小型应用	100万（10^6）	≈ 10^-25	比连中10次彩票还低
中型系统	10亿（10^9）	≈ 10^-19	比被陨石击中的概率还低
大型平台	1万亿（10^12）	≈ 10^-13	几乎不可能
极端压力测试	10^15	≈ 10^-7	千万分之一
理论碰撞点	2.71 × 10^18	≈ 50%	每秒10亿个连续生成86年

换一个角度：如果全世界80亿人每人每秒生成一个UUID v4，需要连续生成约100亿年（约为宇宙年龄的7倍）才有50%的碰撞概率。所以在工程实践中，UUID v4的碰撞风险可以安全地忽略不计。

UUID在数据库中的性能考量

UUID作为数据库主键有很多优势（全局唯一、可离线生成、不泄露业务信息），但也有性能上的注意事项：

存储空间：UUID占16字节（以BINARY(16)存储）或36字节（以CHAR(36)存储），比4字节的INT或8字节的BIGINT大得多。对于上亿行的表，这会显著增加索引大小和内存占用。
索引性能（关键问题）：UUID v4是完全随机的，作为主键插入B+树索引时会导致大量随机IO和页面分裂。InnoDB的聚簇索引按主键物理排序，随机UUID会让每次插入都可能写入不同的数据页，严重影响写入性能（可能比自增ID慢5-10倍）。
解决方案：使用UUID v7（时间有序）代替v4；或使用MySQL 8.0+的UUID_TO_BIN(uuid, 1)函数（时间位重排列）；或在应用层使用Snowflake ID、ULID等有序ID方案。
查询优化：始终使用BINARY(16)而非VARCHAR(36)存储UUID；建立合适的索引；避免在大表上用UUID进行范围查询。

各编程语言中生成UUID

语言/平台	生成方式	版本
JavaScript	crypto.randomUUID()	v4
Python	uuid.uuid4() / uuid.uuid1()	v4 / v1
Java	UUID.randomUUID()	v4
Go	github.com/google/uuid	v1/v4/v6/v7
C#/.NET	Guid.NewGuid()	v4
PostgreSQL	gen_random_uuid()	v4
MySQL 8.0+	UUID()	v1（注意不是v4）

什么时候该用哪个版本？

大多数情况：使用UUID v4。它最简单、最安全、最通用，所有语言和平台都有原生支持。
数据库主键：使用UUID v7。它兼具唯一性和时间有序性，能大幅提升数据库写入性能。
确定性生成：使用UUID v5（优先）或v3。当你需要"相同输入始终得到相同UUID"时使用，例如根据URL生成固定的资源标识符。
需要提取时间信息：使用UUID v1或v7。v1可以反向解析出精确到100纳秒的创建时间。
不建议使用：UUID v2（几乎没有实际应用）、UUID v1用于公开场景（会泄露MAC地址和精确创建时间）。

💡 小贴士：在实际项目中选择ID方案时，还需要考虑UUID之外的替代方案：Twitter的Snowflake ID（64位，时间有序，但需要机器ID协调）、ULID（兼容UUID格式，时间有序，可按字典序排序）、NanoID（更短的随机ID，适合URL）。如果你的系统是单体应用且不需要分库分表，自增ID仍然是最简单高效的选择。只有在分布式系统、微服务间通信、或需要在客户端预生成ID的场景下，UUID才是必要的。另外记住：永远不要把UUID当作密码或安全令牌使用——v1可被预测，v4虽然随机但长度固定，应使用专门的加密随机数生成安全令牌。