UUID适合做索引字段吗

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

简短结论：UUID 可以做索引字段，但不一定“适合”，要看使用场景和 UUID 的类型。

下面分点说明。

一、UUID 做索引的优缺点

✅ 优点

全局唯一
- 适合分布式系统、多库多表合并、数据同步
可在应用层生成
- 不依赖数据库自增
安全性较好
- 比自增 ID 更难被猜测（如 /user/123 vs /user/uuid）

❌ 缺点（重点）

索引体积大
- UUID 通常 16 字节（binary）或 36 字符（string）
- 比 BIGINT（8 字节）大一倍
插入性能差（尤其 MySQL InnoDB）
- UUID 无序 → 导致 B+ 树索引频繁分裂
- 写入越久，性能下降越明显
缓存命中率低
- 随机性导致页分裂、磁盘 IO 增加

二、不同数据库中的表现

MySQL / InnoDB

❌ 不推荐直接用普通 UUID 做主键
✅ 可用 UUIDv7（时间有序）
✅ 或存为 BINARY(16) 而非 CHAR(36)

PostgreSQL

✅ 支持 uuid 类型，性能尚可
✅ 仍推荐 UUIDv7 / ULID

MongoDB

✅ _id 默认就是 UUID-like（ObjectId）
设计上已优化

三、更好的替代方案

1️⃣ UUIDv7（强烈推荐）

时间戳在前，近似有序
兼顾唯一性与写入性能

2️⃣ ULID

字典序可读
时间排序友好

3️⃣ 雪花 ID（Snowflake）

64 位整数
有序、紧凑、适合索引

4️⃣ 自增 ID + 业务 UUID

主键：BIGINT
业务字段：uuid（唯一索引）

四、什么时候适合用 UUID 做索引？

✅ 适合：

分布式系统
多数据中心
需要暴露给外部的 ID
数据合并 / 同步频繁

❌ 不适合：

超高写入量的核心表
纯内部、单库系统
对延迟极度敏感的场景

五、最佳实践建议

主键用有序 ID，UUID 作为业务唯一标识

例如：

id        BIGINT PRIMARY KEY
uuid      BINARY(16) UNIQUE

如果你愿意，我可以：

对比 UUID vs 自增 ID 的性能测试
给你一个 UUIDv7 的实现示例
针对你用的数据库给具体方案

向AI问一下细节

UUID适合做索引字段吗

一、UUID 做索引的优缺点

✅ 优点

❌ 缺点（重点）

二、不同数据库中的表现

MySQL / InnoDB

PostgreSQL

MongoDB

三、更好的替代方案

1️⃣ UUIDv7（强烈推荐）

2️⃣ ULID

3️⃣ 雪花 ID（Snowflake）

4️⃣ 自增 ID + 业务 UUID

四、什么时候适合用 UUID 做索引？

五、最佳实践建议

猜你喜欢

最新资讯

相关推荐

相关标签