uuid主键导致聚簇索引频繁分裂，因innodb按主键物理排序，而v4 uuid完全随机，插入总落在b+树中间页，页满即分裂为两半页，引发i/o与cpu陡增；实测百万级表填充率常低于70%，show engine innodb status频现“pages split due to insert”。
为什么UUID主键会导致聚簇索引频繁分裂
InnoDB 的聚簇索引按主键值物理排序存储数据，而 UUID() 或 UUID.randomUUID() 生成的 v4 UUID 是完全随机的 16 字节序列。插入时，新记录大概率落在 B+ 树中间页而非末尾，触发 page split：满页被拆成两个半页，复制数据、更新指针、写入磁盘——I/O 和 CPU 开销陡增。实测百万级表页填充率常低于 70%，SHOW ENGINE INNODB STATUS 中频繁出现 Pages split due to insert 日志。
用 UUID_TO_BIN() + 时间戳左移（MySQL 8.0+）
MySQL 8.0.31+ 支持 UUID_TO_BIN(uuid, 1)，第二个参数为 1 时会将时间戳高位左移到字节序最前，让生成的二进制具备时间局部性。这比默认的 UUID_TO_BIN(uuid, 0)（仅去掉连字符）效果显著得多。
- 建表必须用
BINARY(16)存储，不能用CHAR(36) - 插入时统一走
UUID_TO_BIN('xxx-xxx', 1)，应用层无需改逻辑，但需确保所有入口都调用该函数 - 查询时用
BIN_TO_UUID(id, 1)转回可读格式，或直接用二进制比较 - 注意：若已有旧数据是
UUID_TO_BIN(uuid, 0)存的，混用会导致排序错乱
换用真正有序的替代方案（推荐 ULID 或 Snowflake）
与其在 UUID 上打补丁，不如换更适配 InnoDB 的 ID 类型。ULID 和 Snowflake 都天然趋势递增，且已验证在高并发写入下页分裂极少。
-
ULID：48 位毫秒时间戳 + 80 位随机数，字符串形式（如01ARZ3NDEKTSV4RRFFQZFSM5BG）字典序可排序；存为CHAR(26)或BINARY(16)，兼容 UUID 语义 -
Snowflake：64 位整数，含时间戳 + worker_id + sequence；必须用BIGINT UNSIGNED存储，避免负数问题；禁止前端直传，须由服务端或 DB 代理层生成 - 如果业务强依赖“对外暴露 UUID”，可用自增主键 +
uuid字段组合：主键用BIGINT AUTO_INCREMENT，另设uuid CHAR(36) UNIQUE NOT NULL用于 API 返回
配合 InnoDB 参数与写入节奏微调
单靠换 ID 类型不够，页分裂是聚簇索引结构、缓冲池管理、写入模式三者共同作用的结果。
- 设
innodb_fill_factor = 70：预留 30% 空间减少分裂频次（但磁盘占用上升） - 批量插入时用
INSERT INTO t VALUES (), (), ()，禁用innodb_autoinc_lock_mode = 0（传统锁模式），改用= 2（交错模式）提升并发写入吞吐 - 避免高频单行插入，尤其在 UUID 主键表上——哪怕只是日志类小表，长期积累也会导致
Data_free持续增长、缓冲池命中率下滑
真正容易被忽略的是：UUID 的“顺序化”不等于“时间戳前置”，而是字节序必须让高位时间信息主导比较逻辑；很多团队用了 UUID_TO_BIN(uuid, 0) 还以为优化完成了，结果页分裂照旧。
