自增ID能避免页分裂、减少碎片和随机IO，而UUID主键导致页分裂频繁、查询变慢、锁竞争加剧；迁移需谨慎，推荐BINARY(16)存储并前置时间戳。
自增ID在InnoDB中不是“更好用”，而是直接决定了B+树聚簇索引能否高效运转——用UUID当主键，等于主动给写入和查询埋雷。
自增ID如何避免页分裂
InnoDB的聚簇索引要求数据物理顺序与主键逻辑顺序一致。自增ID插入时总是追加到B+树最右叶子节点末尾，页满就顺次分配新页，几乎不触发页分裂。而UUID是随机值，每次插入都要先搜索定位位置，大概率落在中间页里，一旦目标页已满（InnoDB默认填充因子15/16），就必须做页分裂：把原页约一半数据挪到新页，还要更新父节点指针。实测百万级写入，UUID主键表的Data_free值通常是自增ID表的3倍以上，说明碎片严重。
- 检查碎片：运行
SHOW TABLE STATUS LIKE 'orders'，重点关注Data_free字段 - 页分裂开销不止是CPU，还涉及磁盘I/O——被挤出的页可能已刷盘，又要重新读回Buffer Pool
- 高并发下多个事务同时往不同中间页插入，会加剧锁竞争，死锁概率上升
UUID作为主键时索引查询变慢的真实原因
范围查询失效不是因为“索引没建好”，而是物理存储彻底打散。比如WHERE id BETWEEN 'a' AND 'z'在UUID主键表上，逻辑相邻的ID在磁盘上可能分散在几百个不连续页里，变成大量随机IO；而自增ID下，这类查询通常只读几个连续页。更隐蔽的是隐式类型转换：WHERE id = 123查BIGINT主键能走索引，但查CHAR(36)主键时，如果应用传的是'123'或漏掉横杠的32位字符串，MySQL无法匹配，直接退化为全表扫描。
- 验证执行计划：对UUID主键表跑
EXPLAIN SELECT * FROM users WHERE id = '9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d'，确保type是const而非ALL - 必须严格校验传参格式：CHAR(36)字段只接受标准格式
'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'，大小写、横杠缺一不可 - 联合索引里千万别把UUID放最左，否则
WHERE user_id = ? AND created_at > ?这种查询基本丧失范围能力
想换回自增ID？别直接ALTER TABLE
线上表从UUID切自增ID不是改个字段类型那么简单。InnoDB要重建整个聚簇索引，千万级表锁表时间常超20分钟；若存在外键约束（比如order_id字段引用该UUID主键），ALTER TABLE MODIFY id BIGINT AUTO_INCREMENT会直接报错ERROR 1832 (HY000): Cannot change column 'id': used in a foreign key constraint。二级索引、触发器、复制延迟都会被牵连。
- 安全迁移路径：新增
new_id BIGINT AUTO_INCREMENT列→用INSERT ... SELECT批量生成→停写→切换应用逻辑→删旧主键列 - 如果必须保留UUID语义，至少转成
BINARY(16)并用UUID_TO_BIN(UUID(), TRUE)（MySQL 8.0+），把时间戳高位前置提升局部性 - 永远不要用
UUID()原生函数结果直接存主键——36字符、带横杠、字符集排序慢，纯属自伤
真正难的不是选自增还是UUID，而是意识到主键设计一旦落地，后续修改成本远高于初期决策。尤其当表已有千万行、关联着十几个外键、支撑着核心交易链路时，一个主键类型选择，实际是在给未来两年的DBA和后端工程师挖坑。
