UUID主键必然引发页分裂，因InnoDB聚簇索引按主键字节序物理排序，v4 UUID为128位完全随机二进制，插入99%以上落在B+树中间页，页满即分裂；UUID_TO_BIN(uuid, 1)可将时间戳高位左移实现近似递增，压降90%分裂但无法根治，ULID或Snowflake才是更优替代方案。
MySQL 用随机 UUID（比如 UUID() 生成的 v4 或未重排的 v1）直接当主键，会显著引发页分裂和性能下降——这不是配置问题，而是由 InnoDB 聚簇索引的底层机制决定的。
聚簇索引要求物理有序，但 UUID 是逻辑乱序的
InnoDB 的主键就是聚簇索引，整张表的数据按主键值**物理排序存储**在 B+ 树叶子节点里。新数据插入时，InnoDB 必须找到它该落脚的页，并把记录“塞进去”。
- 自增 ID 总是递增，新行永远追加到最后一片数据页末尾，写入是顺序的、局部的；
- 随机 UUID（如
'a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8'）字节序列完全无时间或空间规律，每次插入都大概率落在已有数据页的中间位置； - B+ 树要维持有序，就得在目标页内二分查找插入点——这个过程本身不慢，但一旦目标页已满（16KB），就必然触发页分裂。
页分裂不是小开销，而是 I/O 和锁的连锁反应
页分裂不是简单“多分一页”，而是一连串高成本操作：
- 原页约一半记录被复制到一个新分配的磁盘页；
- 原页剩余空间利用率骤降（常低于 50%），形成索引碎片；
- 父节点要更新指针，若父页也满了，可能级联分裂；
- 整个过程需加页锁、写 doublewrite buffer、触发随机磁盘 I/O；
- Buffer Pool 中缓存的页变得离散，后续查询命中率明显下滑。
实测显示：每插入 1000 条 UUID 主键记录，平均引发 1.7 次页分裂；而自增主键基本为 0。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
字符串 vs BINARY 存储，都没解决“无序”这个根子
很多人以为把 CHAR(36) 改成 BINARY(16) 就能治本，其实只是缓解了空间浪费：
-
CHAR(36)占 36 字节，比较慢、二级索引体积大； -
BINARY(16)占 16 字节，节省空间、比较快，但字节顺序仍是原始 UUID 的随机排列； - InnoDB 按字节逐个比对，v4 UUID 前 4 字节不反映生成时间，B+ 树插入位置依然不可预测；
- 所以页分裂照旧，Buffer Pool 利用率照跌，范围查询（
WHERE id > ?）仍难走索引。
真正有效的解法：让 UUID 具备时间局部性
MySQL 8.0.1+ 提供了 UUID_TO_BIN(uuid(), 1)，其中 swap_flag = 1 会重排字节序：
- 把 v1 UUID 中的时间戳高位（前 6 字节）移到最前面；
- 同时交换字节序，使二进制值近似按生成时间递增；
- 配合
BINARY(16)字段类型，才能让 B+ 树插入趋于尾部聚集； - 注意：
UUID_TO_BIN(uuid())（无第二参数）不重排，等同于白转。
这样做的效果是页分裂率比普通 UUID 降低约 90%，但仍高于自增 ID——因为同一毫秒内多个 UUID 后缀仍是随机的，高并发下仍有局部拥挤风险。
