随机主键会拖慢插入，因为InnoDB以主键构建聚簇索引，随机值导致频繁页分裂、数据移动和磁盘随机写，降低吞吐量并加剧碎片化。
主键不建议用随机值（如 UUID、雪花ID 或 MD5）直接作为聚簇索引的键，尤其在 InnoDB 中会导致严重的插入性能下降和磁盘碎片问题。
为什么随机主键会拖慢插入？
InnoDB 默认以主键构建 B+ 树聚簇索引，数据行按主键物理排序存储。若主键是随机生成的（比如 UUID），新记录大概率无法追加到页末尾，而需插入到中间甚至前部的已满数据页中——这会触发频繁的页分裂（page split）、数据移动和磁盘随机写，显著降低写入吞吐量，同时加剧碎片化。
常见随机主键的隐患场景
- UUID（字符串型）：32 位十六进制字符串，无序且长度大，索引体积膨胀，缓存命中率低；
- 雪花ID（数值型但时间不严格递增）：虽为 64 位整数，但若机器 ID / 序列号分布不均，或时钟回拨导致局部乱序，仍可能打乱插入局部性；
- MD5/SHA 哈希值作主键：完全无序，对范围查询、分页、ORDER BY 都极不友好。
更优的主键设计方案
兼顾唯一性、高效插入与查询，推荐以下组合策略：
- 自增 BIGINT 主键 + 业务唯一标识字段：主键保持递增，保证聚簇索引写入效率；另建唯一索引（UNIQUE KEY）约束业务字段（如 order_no、user_code），满足业务查询需求；
- 有序 UUID（如 ULID 或 COMB）：前缀嵌入时间戳，使 UUID 具备一定顺序性，缓解乱序问题（但仍有额外开销，适合分布式且必须用字符串主键的场景）；
- 复合主键（谨慎使用）：仅当天然存在高区分度、高局部性的组合字段（如 (date, id)），且能确保插入趋势稳定时考虑，否则易引入复杂性。
已有随机主键表的优化建议
若系统已上线且主键为 UUID 等随机值，可逐步优化：
- 添加 AUTO_INCREMENT 的隐藏代理主键（如
id BIGINT PRIMARY KEY AUTO_INCREMENT FIRST），原 UUID 字段降级为唯一索引； - 执行
ALTER TABLE ... ORDER BY id;（仅限 MyISAM）或通过导出导入重建表（InnoDB），强制物理重排，减少碎片； - 监控
InnoDB_buffer_pool_read_requests与InnoDB_buffer_pool_reads比值，判断因碎片导致的缓存失效是否改善。
主键不是越“唯一”越好，而是要匹配存储引擎特性与实际访问模式。递增、紧凑、语义中立的主键，才是高性能写入的基础。
