自增ID是InnoDB聚簇索引高效运转的底层前提，因其顺序插入避免页分裂、减小二级索引体积、提升并发吞吐；而UUID或伪有序业务ID会导致中间页插入、频繁分裂、I/O放大及缓存命中率下降。
自增ID不是“更方便”，而是InnoDB聚簇索引能稳定高效运转的底层前提——不用它，写入性能、二级索引体积、并发吞吐都会被悄悄拖垮。
为什么自增ID能避免页分裂
InnoDB按主键顺序物理存储数据，新行必须插到B+树叶子节点的逻辑位置。自增ID保证每次插入都落在当前最右页末尾，页满就分配新页，旧页不动；而UUID或业务编码（如20260501000001）会导致插入点随机落在中间页，一旦该页利用率超90%，立刻触发页分裂：搬走约一半行、更新父节点指针、可能连带调整上层节点。
- 观察证据：
SHOW TABLE STATUS LIKE 't'中Data_free持续 > 表总大小5%（如 >1GB），基本可判定分裂严重 - 常见错误：用
CONCAT(DATE_FORMAT(NOW(),'%Y%m%d'), LPAD(id,6,'0'))伪装有序，但不同时间生成的ID仍会交叉回插，照样分裂 - 真正关键：页分裂不只是“写慢”，它让原本在Buffer Pool里的页被挤出，后续查询又要重新从磁盘读回，放大I/O开销
为什么主键小直接影响所有二级索引体积
InnoDB每个二级索引（如 INDEX idx_name ON users(name)）的叶子节点里存的不是行指针，而是**主键值本身**。主键长度直接乘以所有二级索引的行数，就是额外空间开销。
-
INT主键：每条二级索引记录占4字节 -
VARCHAR(36)存UUID（UTF8MB4）：实际可能达144字节，同样1000万行，二级索引体积差3–9倍 - 常见错误：把
CHAR(36)当主键，没转成BINARY(16)；误以为“主键只用一次，空间无所谓” - 后果：索引变大 → Buffer Pool缓存命中率下降 → 更多磁盘随机读
高并发下自增ID的锁行为要看 innodb_autoinc_lock_mode
自增ID并非天然无锁。InnoDB通过该参数控制锁粒度，三种模式差异极大：
-
innodb_autoinc_lock_mode = 0（传统模式）：每条INSERT都加表级AUTO_INC锁 → 高并发下严重排队 -
innodb_autoinc_lock_mode = 1（默认）：单条INSERT只持轻量mutex；批量INSERT SELECT加语句级锁 → 平衡安全与性能 -
innodb_autoinc_lock_mode = 2（交错模式）：非事务性INSERT不加锁，但无法保证语句级连续性，复制场景慎用 - 实操建议：建表时明确声明
id BIGINT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT；避免手动INSERT INTO t VALUES (123, ...)覆盖自增值
换主键的成本远高于初期决策
线上表从UUID切自增ID不是改个字段类型那么简单。InnoDB必须重建整个聚簇索引，千万级表锁表常超20分钟；若存在外键约束（如 order_id 引用该UUID主键），ALTER TABLE MODIFY id BIGINT AUTO_INCREMENT 会直接报错 ERROR 1832。
- 真正难的不是选自增还是UUID，而是意识到主键设计一旦落地，后续修改牵连二级索引、触发器、复制延迟、应用逻辑，成本指数级上升
- 如果必须保留UUID语义，至少用
BINARY(16)存储，并确保时间戳高位前置（MySQL 8.0+支持） - 永远不要用原生
UUID()函数结果直接存主键——36字符、带横杠、字符集排序慢，纯属自伤
