UUID主键必然引发页分裂，因随机性导致B+树频繁分裂；应改用BINARY(16)存储并启用UUID_TO_BIN(UUID(),1)实现近似有序，超千万量级时建议代理键或组合主键。
直接用 UUID 做主键（尤其是 CHAR(36) 或未处理的 UUID()）几乎必然引发页分裂，这不是配置问题，而是 B+ 树物理写入机制决定的。优化核心就两条：改存储格式 + 改排序逻辑。
为什么 UUID 主键会频繁触发页分裂
InnoDB 的聚簇索引按主键值顺序物理存放数据页。UUID v4 是完全随机的 128 位值，新插入的 id 几乎总落在已有页的中间位置，导致原页无法容纳、必须分裂——实测页填充率从自增 ID 的 80%+ 降到 60% 以下。分裂不仅消耗 CPU 和 IO，还会产生碎片页，长期积累后 SELECT 延迟上升 200%+。
必须把 CHAR(36) 换成 BINARY(16)
字符串形式的 UUID 占 36 字节，而二进制压缩后仅 16 字节。这个改动本身不解决分裂，但能减少 55% 存储开销，并让每个索引页多存约 2 倍记录，间接缓解树高增长和缓存压力。
操作要点：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 建表时主键类型必须声明为
BINARY(16)，不是VARBINARY或CHAR - 插入时强制调用
UUID_TO_BIN(UUID())，不能靠应用层拼字符串再入库 - 查询时同样用
BIN_TO_UUID(id)转换展示，避免在 WHERE 中对二进制字段做函数运算（会失效索引）
优先启用 UUID_TO_BIN(UUID(), 1) 启用时间排序
MySQL 8.0+ 的 swap_flag = 1 参数会把 UUID v1/v4 的时间戳部分移到高位，生成近似单调递增的二进制值。它不是严格递增（因毫秒级精度+随机后缀），但已足够大幅降低页分裂频率——实测写入吞吐提升 40%，页分裂下降 85%。
注意点：
-
UUID_TO_BIN(UUID(), 1)只对 MySQL 自带的UUID()（v1 变体）有效；若应用生成的是 v4，需改用 v7 或自行实现时间前缀拼接 - 不要在
ORDER BY中依赖该值做“精确时间排序”，它只保证大致时间局部有序 - 如果业务强依赖时间序（如消息时间线），建议直接上
UUIDv7（MySQL 8.0.36+ 原生支持）
复杂场景下考虑组合主键或代理键
当数据量超千万、写入 QPS 稳定高于 5k，且无法升级到 MySQL 8.0.36+ 时，单靠 UUID_TO_BIN(..., 1) 仍可能遇到热点页竞争。这时应放弃纯 UUID 思路：
- 加
shard_id TINYINT构成联合主键(shard_id, id)，把写入分散到多个逻辑页段 - 更稳妥的做法是回归自增
BIGINT代理主键，把原始 UUID 改为UNIQUE索引，兼顾查询兼容性与写入性能 - 分库分表环境下，
shard_id应由业务层计算（如取用户 ID 哈希模 16），避免数据库层路由开销
真正容易被忽略的点是：页分裂一旦发生，不会自动回填。即使后续改用有序 UUID，旧分裂产生的碎片页仍长期存在，必须配合 OPTIMIZE TABLE 或重建表才能回收空间。
