数据库存UUID要注意什么

发布时间：2026-09-06 13:48:11 来源：亿速云阅读：97 作者：小樊栏目：数据库

在数据库里存 UUID（通用唯一标识符）时，有几个性能、存储、可读性、兼容性方面的注意点。下面按常见场景总结：

1. 存储类型选择（最重要）

✅ 推荐：用专用 UUID / BINARY 类型

MySQL 8.0+：BINARY(16) 或 UUID 类型（8.0 原生支持）
PostgreSQL：uuid 类型（原生最优）
SQL Server：uniqueidentifier

❌ 不推荐：CHAR(36) / VARCHAR(36)

占用空间大（36 字节 vs 16 字节）
比较慢（字符串比较）
索引膨胀明显

✅ 最佳实践（MySQL）：

id BINARY(16) NOT NULL

2. UUID 版本选择

常见 UUID 版本：

UUIDv1：基于时间+MAC，有序，但泄露 MAC
UUIDv4：随机，最常用
UUIDv7（新趋势）：时间有序 + 随机，非常适合数据库主键

✅ 数据库主键建议：

高并发写场景 → UUIDv7
普通业务 → UUIDv4 也可

3. 主键 & 索引问题（高性能关键）

UUID 做主键的坑

UUID 无序 → 导致 B+树页分裂
写放大、碎片多
索引比自增 ID 大很多

解决方案

使用 UUIDv7（有序）
或用 雪花 ID / 自增 ID + UUID 业务键
如果必须用 UUIDv4：
- 不作为聚簇索引（如 InnoDB）
- 用自增 ID 做主键，UUID 做唯一索引

4. 应用层生成 vs 数据库生成

方式	优点	缺点
应用层生成	分布式友好	需注意版本
数据库生成	简单	不利于分库分表

✅ 分布式系统：应用层生成 UUID

5. 可读性与调试

UUID 不利于：

日志排查
人工比对
运维

建议：

对外暴露使用 短 ID（如 NanoID）
内部用 UUID

6. 排序与范围查询

UUID 不适合：

BETWEEN
按时间排序

如果常按时间查：

加 created_at
或用 UUIDv7

7. 安全性和隐私

UUIDv1 可能暴露 MAC 地址
UUIDv4 不可预测（适合 token）
不要用 UUID 当密码或权限凭证

总结建议（直接抄）

✅ 最佳实践：

PostgreSQL：uuid
MySQL：BINARY(16) + UUIDv7
主键避免纯随机 UUID
对外不用 UUID

如果你告诉我：

用什么数据库
是否做主键
是否分布式

我可以直接给你表结构 + 生成代码。

向AI问一下细节