17370845950

UUID.randomUUID() 是最安全的随机 UUID 生成方式，基于 SecureRandom 实现、线程安全、无重复风险；但其无序性损害数据库写入性能，不宜直接用作主键，推荐 Snowflake 等有序方案替代。

UUID.randomUUID() 是最常用也最安全的生成方式

Java 的 UUID 类本身不负责“生成”逻辑，它只是对 128 位值的封装；真正生成随机 UUID 的是静态工厂方法 UUID.randomUUID()。它基于 java.security.SecureRandom 实现，线程安全，无需额外同步。

常见误区是以为 UUID 构造函数能“自定义生成”，但所有带参数的构造函数（如 UUID(long, long)）都只是把已有数据转为对象，不参与随机性构建。

• 每次调用 UUID.randomUUID() 都产生一个新实例，值几乎不可能重复（理论碰撞概率约 2^(-122)）
• 不依赖系统时间或 MAC 地址，规避了时钟回拨和硬件暴露风险
• 生成开销略高于纯数字 ID（约 2–5μs/次），但在绝大多数业务场景中可忽略

不要用 UUID.nameUUIDFromBytes() 做业务主键

UUID.nameUUIDFromBytes(byte[]) 是确定性哈希（MD5），输入相同字节数组永远输出相同 UUID。这在需要“可预测 ID”的场景（如缓存键、幂等 ID）有用，但极易引发冲突或泄露业务信息。

典型错误：用用户手机号或邮箱直接哈希生成 ID —— 一旦攻击者知道规则，就能反推原始数据或批量构造有效 ID。

• 仅适用于内部标识映射，且输入源必须可控、长度固定、无敏感含义
• 若需确定性 ID，优先考虑加盐后哈希再截断，或使用专用库如 com.google.common.hash.Hashing
• 数据库索引对 UUID 的写入性能影响比自增 ID 高约 30%～50%，尤其在 B+ 树页分裂频繁时

toString() 输出带连字符，入库前注意字段长度

UUID.toString() 返回形如 "f47ac10b-58cc-4372-a567-0e02b2c3d479" 的 36 字符字符串（32 字符 + 4 个短横）。若存入数据库，VARCHAR(36) 是安全选择；但若追求空间效率，可存为 16 字节二进制（BYTEA 或 BINARY(16)）。

• PostgreSQL 支持原生 UUID 类型，自动校验格式且存储紧凑（16 字节）
• MySQL 8.0+ 同样支持 UUID 类型，但旧版本常用 CHAR(36) 或 BINARY(16)
• 用 uuid.getMostSignificantBits() 和 uuid.getLeastSignificantBits() 可拆分为两个 long，便于某些序列化或调试场景

分布式系统中 UUID 不等于“全局有序”

很多人误以为 UUID 天然适合分库分表场景，其实标准随机 UUID（version 4）完全无序，会导致 MySQL InnoDB 主键插入时频繁页分裂，写入吞吐下降明显。

如果需要兼顾唯一性与写入性能，应避免直接用 UUID.randomUUID() 作主键，而改用：

String id = String.format("%d%012d", System.currentTimeMillis(), ThreadLocalRandom.current().nextLong(1000000000000L));

或更稳妥的 Snowflake 变种（如 Twitter 的 idworker 或 Apache ShardingSphere 的 SNOWFLAKE 算法）。

真正要用 UUID 时，至少确保数据库主键不是聚簇索引，或使用 UUID.toByteArray() 后按字节倒序存入（模拟时间前缀效果），但这已超出标准库能力范围。