UUID 作主键性能差因 InnoDB 聚簇索引要求有序插入，而 v4 UUID 随机导致页分裂频繁、存储开销大（CHAR(36)）、比较慢；改用有序 UUID（v1/v7）、ULID、Snowflake 或自增 +UUID 组合可显著优化。
MySQL 用 UUID 做主键，性能确实容易出问题——不是 UUID 本身不好，而是它和 InnoDB 的聚簇索引机制“不对付”。核心矛盾就两点：插入无序导致页分裂频繁，以及字符串类型带来存储和比较开销。解决方向也很明确：要么让 UUID 变有序，要么换更合适的 ID 类型。
为什么 UUID 主键会拖慢数据库
InnoDB 表数据按主键物理排序存放（聚簇索引）。自增 ID 总是追加到末尾，写入高效；而标准 UUID v4 是完全随机的，每次插入都可能落在索引中间位置：
- 目标数据页已满时，必须做页分裂——拆分页、复制数据、更新指针，I/O 和 CPU 开销陡增
- 长期下来，B+ 树变深、页填充率下降（实测百万级表常低于 70%）、碎片率升高
- CHAR(36) 存储占 36 字节，是 BIGINT(8) 的 4.5 倍；所有二级索引都冗余该主键，索引体积显著膨胀
- 字符串比较比整数慢，JOIN、ORDER BY、WHERE 等操作响应延迟明显上升
让 UUID 变“有序”：真正可用的顺序化方案
不改主键类型，也能缓解问题——关键是让 UUID 的生成具备时间局部性，避免完全随机：
- 优先用 UUID v1 或 v7：v1 含时间戳高位 + MAC 地址，v7 是专为排序设计的新标准（前 48 位毫秒时间戳），天然支持字典序递增，插入位置相对集中
- 存储优化：去掉连字符，转为 BINARY(16)：从 36 字节压缩到 16 字节，减少索引体积和比较开销；应用层可统一处理格式转换
- 避免客户端自由生成 v4：Java 的 UUID.randomUUID()、Node.js 的 crypto.randomUUID() 都是强随机，高并发下极易触发页分裂，应禁用或替换
更推荐的替代方案：兼顾唯一性与性能
如果业务允许主键类型变更，以下方案在真实场景中被反复验证更优：
- ULID（推荐首选）：128 位，前 48 位毫秒时间戳 + 后 80 位随机数，字符串形式（如
01ARZ3NDEKTSV4RRFFQZFSM5BG）天然字典序可排序，存为 CHAR(26) 或 BINARY(16)，兼容 UUID 语义且性能接近自增 - Snowflake 或 Leaf-segment ID：64 位整数，含时间戳 + 节点标识 + 序列号，紧凑、趋势递增；用 BIGINT UNSIGNED 存储，二级索引体积小，插入稳定；注意校准时钟漂移，避免乱序
- 自增主键 + 业务唯一字段组合 ：主键用 BIGINT AUTO_INCREMENT，另设 UUID 字段（UNIQUE NOT NULL）作对外暴露 ID（如 API 返回、订单号），兼顾性能与防遍历需求
已有 UUID 主键表的应急与长期优化
线上系统已用 UUID 主键且出现性能下滑，可分阶段应对：
- 短期止血 ：对大表执行
OPTIMIZE TABLE（或使用在线 DDL 工具），整理碎片、重建索引、提升页填充率 - 中期过渡 ：新增自增列作为新主键，原 UUID 列改为 UNIQUE NOT NULL；逐步将外键、关联查询、应用逻辑切换至新主键
- 长期根治 ：新建表采用 ULID 或 Snowflake 方案，通过双写 + 迁移 + 切流方式灰度替换，确保零数据丢失与服务连续
