🆔 UUID 使用指南：自增 ID 还是 UUID？开发者该如何选择

什么是 UUID

UUID（Universally Unique Identifier，通用唯一标识符）是一个 128 位（16 字节）的标识符标准，由国际标准化组织在 ISO/IEC 11578 中定义。它由 32 个十六进制数字组成，通常以 8-4-4-4-12 的形式用连字符分组显示：550e8400-e29b-41d4-a716-446655440000。

UUID 的核心价值在于"全球唯一"：只要按照规范生成，任何人在任何时间、任何设备上生成的 UUID 几乎不可能重复。这意味着你不需要一个中心服务器来分配 ID，分布式系统中的每个节点都可以独立生成唯一标识。

UUID 的主要版本

• v1（基于时间） — 由时间戳、时钟序列和节点 MAC 地址生成，包含生成时间和设备信息，可追踪性带来隐私风险
• v4（基于随机数） — 完全由随机数生成（122 位随机），不包含任何时间或设备信息，隐私性最好，是目前最常用的版本
• v7（基于时间排序） — 结合时间戳与随机数，既能保证唯一性，又具有时间排序特性，对数据库索引友好，是新兴推荐方案

在大多数现代场景中，UUID v4 是最稳妥的选择：无需依赖硬件信息，隐私安全，生成简单。如果你的数据量很大且对索引性能敏感，可以关注 v7。

自增 ID 与 UUID 对比

维度	自增 ID	UUID
唯一性	仅在单库内唯一	全球唯一
生成方式	依赖数据库自增	客户端可独立生成
信息泄露	可推测业务量	不可推测
存储占用	4-8 字节	16 字节
索引性能	顺序插入，性能好	随机插入，可能页分裂
分布式支持	需全局协调	天然支持

如何选择

优先使用 UUID 的场景

• 分布式系统、微服务架构，需要多节点独立生成 ID
• 数据需要跨库合并、迁移或同步
• ID 暴露在 URL 或 API 中，不希望被枚举探测
• 客户端需要预先生成 ID（如离线场景）

优先使用自增 ID 的场景

• 单机小型应用，数据量不大，无合并需求
• 对存储空间和索引性能要求极高
• 业务上需要连续可读的编号（如订单号、票据号）

数据库中的最佳实践

如果选择 UUID 作为主键，MySQL 中可以将其存储为 BINARY(16) 类型（将 UUID 字符串转为 16 字节二进制），比直接存 VARCHAR(36) 节省约一半空间。PostgreSQL 则提供了原生的 UUID 数据类型，可以直接使用。

对于查询性能敏感的场景，可以考虑使用 UUID v7（时间排序）或雪花算法（Snowflake ID），它们既能满足分布式唯一性，又能保持较好的索引插入顺序。

快速生成 UUID

开发测试或原型验证时，使用我们的 UUID 生成器 可以批量生成 UUID v4（最多 100 个），基于浏览器内置的 crypto.randomUUID() 加密级随机源，一键复制到代码或数据库中。

小结

自增 ID 和 UUID 各有适用场景，没有绝对的优劣。核心原则是：根据你的架构复杂度、数据规模和业务需求做选择。分布式优先考虑 UUID，简单单体优先考虑自增，折中方案则是 v7 或雪花算法。