UUID主键导致索引碎片化，是因为InnoDB聚簇索引要求有序插入，而UUID()生成的随机字符串使新记录大概率插入索引中间位置，引发频繁页分裂、页内空洞和缓冲池命中率下降。
为什么UUID主键会导致索引碎片化
MySQL（尤其是InnoDB）的聚簇索引按主键物理排序存储数据。UUID() 生成的字符串是随机的，新插入记录大概率落在索引页中间而非末尾，触发频繁的页分裂和数据移动，造成页内空洞、页外碎片、缓冲池命中率下降——这不是“慢”，而是持续写入后性能逐步劣化。
常见现象包括：SHOW TABLE STATUS 中 Data_free 值持续增长；innodb_buffer_pool_reads 明显高于 innodb_buffer_pool_read_requests；写入吞吐随时间下降。
改用有序UUID：MySQL 8.0+ 的 UUID_TO_BIN() + UUID_SHORT() 替代方案
MySQL 8.0.1 开始支持 UUID_TO_BIN()，它能把标准 UUID 字符串转为 16 字节二进制，并通过 swap_flag = 1 参数重排字节顺序，把时间戳高位前置，实现近似单调递增。
- 建表时用：
id BINARY(16) PRIMARY KEY DEFAULT (UUID_TO_BIN(UUID(), 1)) - 插入时不传值即可自动填充；若需手动指定，务必用
UUID_TO_BIN('xxx-xxx', 1)，漏掉1会退回随机排序 - 查询时用
BIN_TO_UUID(id, 1)转回可读格式，注意第二个参数必须一致 - 避免在旧版本（<8.0）硬套：没有
swap_flag支持，UUID_TO_BIN()默认仍是随机序
不升级MySQL？用 UUID_SHORT() 或自建时间前缀UUID
UUID_SHORT() 是 MySQL 内置函数，返回 8 字节整型，基于服务器启动时间 + 服务器ID + 递增计数器生成，天然有序、紧凑、可索引友好。但它不是全局唯一（跨实例可能重复），仅适用于单机或严格隔离的分库场景。
- 适用场景：内部管理后台、日志表、非分布式核心业务
- 建表：
id BIGINT UNSIGNED PRIMARY KEY DEFAULT (UUID_SHORT()) - 风险点：服务器重启会重置计数器，高并发下仍可能短时重复（需配合唯一索引+重试）
- 替代做法：用
CONCAT(DATE_FORMAT(NOW(), '%y%m%d%H%i%s'), LPAD(FLOOR(RAND()*10000), 4, '0'))拼时间前缀，但需自行保证并发安全
定期重建索引不能根治，但可临时缓解
OPTIMIZE TABLE 在 MySQL 5.7+ 对 InnoDB 实际执行的是重建表（ALGORITHM=COPY），能消除碎片、重排聚簇索引、更新统计信息。但它锁表时间长、IO压力大，不适合高频写入的线上表。
- 仅建议用于低峰期的只读/低写表，或归档历史分区表
- 替代轻量操作：
ALTER TABLE t ENGINE=InnoDB ALGORITHM=INPLACE（MySQL 5.6+）不锁表，但不会重排主键顺序，仅整理页内碎片 - 监控依据：当
Data_free / Data_length > 0.25且写入明显变慢时再考虑，别设固定周期盲目执行
真正关键的不是“怎么修碎片”，而是“从第一行 INSERT 就避免引入随机性”——有序UUID不是优化技巧，是设计前提。一旦用了原生 UUID() 当主键，后续迁移成本远高于初期选型成本。
