自增主键能显著减少页分裂，uuid主键在innodb下几乎必然引发高频页分裂——这不是配置问题，是b+树物理结构和插入局部性决定的硬约束。
自增主键能显著减少页分裂，UUID主键在InnoDB下几乎必然引发高频页分裂——这不是配置问题，是B+树物理结构和插入局部性决定的硬约束。
为什么UUID主键导致频繁页分裂
InnoDB的聚簇索引就是数据本身，B+树叶子节点按主键值排序存放真实行记录。自增ID（如BIGINT AUTO_INCREMENT）每次插入都落在树的最右端，新记录追加到当前页末尾即可；而UUID是随机字符串，UUID()生成的'550e8400-e29b-41d4-a716-446655440000'这类值在B+树中插入位置完全不可预测。
这意味着：每次INSERT都可能触发以下连锁反应：
- 搜索目标页 → 读取非热点页（随机IO）
- 目标页已满 → 拆分该页为两页（page split）
- 挪动约50%的键值对 + 重建父节点指针
- 拆分后旧页残留大量空闲空间（
Data_free升高）
实测百万级写入后，SHOW TABLE STATUS LIKE 'users'中Data_free常达数MB，碎片率超30%，而自增ID表通常Data_free 。
CHAR(36) vs BINARY(16)：存储格式没解决根本问题
把UUID从CHAR(36)改成BINARY(16)能省20字节，但无法改变“随机插入”这一致命缺陷。MySQL 8.0+支持UUID_TO_BIN(UUID(), TRUE)把时间戳高位前置，略微提升局部性，可降低约15%分裂频率——但依然远不如自增ID的尾插效率。
关键差异在于：
-
CHAR(36)：比较走字符排序规则（如utf8mb4_general_ci），慢且易因大小写/横杠不一致导致索引失效 -
BINARY(16)：二进制比较快，但B+树仍需全局搜索插入点，页分裂照常发生 - 无论哪种，二级索引叶子节点都存完整主键值 →
BINARY(16)比BIGINT多占8字节，同样放大所有二级索引体积
范围查询退化：ORDER BY id变成全表扫描
聚簇索引的物理顺序直接决定范围扫描效率。WHERE id BETWEEN 1000 AND 2000在自增ID下只需读连续几页；但UUID主键下，逻辑上“相邻”的ID在磁盘上可能散落在数百个不同页里，变成随机IO，Buffer Pool命中率暴跌。
更隐蔽的问题是应用层传参：
- ORM默认把数字ID当字符串传 →
WHERE id = '12345'查BIGINT主键会隐式转换，但查CHAR(36)时若传REPLACE(uuid, '-', '')的32位字符串，索引直接失效 - 执行计划里
type显示ALL而非const，就是典型信号 - 联合索引如
(user_id, created_at)，若user_id是UUID，整个索引的范围能力基本归零
ALTER TABLE改主键：线上表别硬切
想把UUID主键换成自增ID？ALTER TABLE users MODIFY id BIGINT AUTO_INCREMENT在千万级表上大概率失败：
- 聚簇索引重建需锁全表，耗时常超20分钟
- 外键约束直接报错：
ERROR 1832 (HY000): Cannot change column 'id': used in a foreign key constraint - 二级索引、触发器、全文索引全部重刷，Buffer Pool雪崩式失效
真要迁移，必须用双写+影子表+数据校验的灰度方案，且order_id等关联字段也得同步改类型，否则外键链路就断了。
真正难处理的不是“能不能换”，而是“换完之后所有业务代码、中间件、监控告警里硬编码的UUID格式校验逻辑，全得重新梳理一遍”。
