UUID主键必然引发页分裂，因InnoDB聚簇索引要求有序插入，而v4 UUID为完全随机字节序，新记录总大概率插入数据页中间位置，一旦页满即触发确定性页分裂，导致I/O激增、碎片增长和缓存命中率下降。
UUID主键为什么必然引发页分裂
InnoDB 的聚簇索引按主键值物理排序存储数据，而 UUID() 生成的是 v4 随机字符串（如 "a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8"），其二进制字节序完全无时间或空间局部性。插入时，新记录大概率落在已有数据页的中间位置——一旦目标页已满，InnoDB 就必须执行页分裂：把原页约 50% 的记录挪到新页，更新父节点指针，同时写入 doublewrite buffer。这不是偶发抖动，而是每次随机插入都可能触发的确定性开销。
常见错误现象包括：SHOW ENGINE INNODB STATUS 中频繁出现 "Pages split due to insert"；监控指标 innodb_page_splits 持续飙升；SHOW TABLE STATUS 显示 Data_free 值不断增长且远高于预期。
CHAR(36) 和 BINARY(16) 存储方式差异不大
很多人以为把 CHAR(36) 改成 BINARY(16) 就能解决性能问题，其实不然。虽然存储体积从 36 字节降到 16 字节，但核心矛盾没变：字节序仍是随机的。InnoDB 比较 UUID 是按字节逐个比对的，v4 UUID 的前 4 字节（时间低位）并不反映生成顺序，所以 BINARY(16) 插入依然无序。
MySQL 8.0+ 提供了 UUID_TO_BIN(uuid, 1)，它会将时间戳左移并重排字节序，让高位携带时间信息，显著提升局部有序性。但注意两点：
- 必须显式启用，
UUID_TO_BIN(uuid, 1)不是默认行为 - 仍需配合
BINARY(16)字段类型，若存回CHAR(36)，转换白做
雪花 ID 并不天然安全
snowflake 生成的是 BIGINT UNSIGNED 类型的递增整数，表面看比 UUID 友好，但实际落地常踩坑：
- 时钟回拨哪怕 1ms，同一毫秒内多个 worker_id 生成的 ID 就可能重复，MySQL 报
ERROR 1062 (23000): Duplicate entry - 分库分表场景下，若
worker_id未全局唯一（比如不同实例用了相同 ID），ID 会碰撞 - 前端直传 ID 绕过服务端校验，等于放弃一致性兜底
- 某些 Go/Java SDK 默认用
System.currentTimeMillis()，未处理闰秒，在金融类系统中可能出偏差
真正可用的方案是：由应用层或数据库代理层（如 Vitess）统一生成，并强制校验时钟偏移。
缓解页分裂不能只靠换主键类型
单纯把主键从 UUID 换成 snowflake 或 ULID，只能缓解，不能根治。页分裂是聚簇索引 + 写入节奏 + 缓冲池管理共同作用的结果。
- 建议搭配
innodb_fill_factor = 70，预留 30% 空间减少分裂频次（代价是磁盘占用上升） - 批量插入时禁用自增锁竞争：
innodb_autoinc_lock_mode = 2，配合INSERT INTO t VALUES (), (), ()多值语法 - 若业务允许，优先用
BIGINT UNSIGNED AUTO_INCREMENT，再通过额外字段存uuid用于外部交互 - 定期重建表（
ALTER TABLE t ENGINE=INNODB）可清理碎片，但会锁表，需评估窗口期
最容易被忽略的一点：页分裂的影响不是线性的。百万级表可能还看不出问题，但当 Data_free 超过总数据量 30%，B+ 树深度增加、缓冲池命中率骤降，查询延迟就会突然恶化——这时再优化，往往已错过黄金窗口。
