自增主键写入快，本质是b+树页分裂更可控，因insert总追加到索引末尾，物理连续写入，避免频繁页分裂和随机磁盘寻址；而uuid等随机主键导致插入位置不可预测，需反复查找、拆分中间页，引发io放大、缓冲池污染及写入吞吐骤降。
MySQL自增主键写入快，本质是B+树页分裂更可控
因为 INSERT 时新记录总追加到索引末尾（或附近），物理上连续写入，避免频繁页分裂和随机磁盘寻址。而随机主键（如UUID）导致新行插入位置完全不可预测，B+树需不断查找、拆分、合并中间页，IO放大严重。
自增主键减少页分裂和缓冲池污染
使用 AUTO_INCREMENT 时，InnoDB通常只需扩展最右侧的叶子页（或分配新页），且该页大概率已在 innodb_buffer_pool 中热着；随机主键则迫使大量非相邻页被加载进缓冲池，挤出热点数据，加剧 Buffer pool hit rate 下降。常见现象包括：
- 写入吞吐骤降，
SHOW ENGINE INNODB STATUS中看到大量pages made young或pages read ahead -
innodb_data_pending_writes持续偏高 - 慢查询日志里出现大量
insert into ... values (...)耗时 >100ms
UUID作为主键的隐性代价不止是写入慢
即使你用 UUID_SHORT() 或 UUID_TO_BIN() 优化了排序性，仍存在几个硬伤：
- 主键变长：从4字节（
INT）或8字节（BIGINT）涨到16字节 → 所有二级索引的PRIMARY KEY副本都变大，索引体积膨胀约2–3倍 - 范围扫描失效：
WHERE id BETWEEN ? AND ?在UUID上几乎无意义，优化器常放弃使用索引 - 复制延迟敏感：基于语句的复制（SBR）下，UUID生成时机不一致会导致主从数据不一致（虽已默认ROW格式，但仍有配置残留风险）
什么时候可以考虑非自增主键？
仅当满足全部以下条件时才值得权衡：
- 业务要求全局唯一且跨库/分片不依赖中心ID生成器（例如多活架构）
- 写入量极低（QPS
- 已用
UUID_TO_BIN(uuid, true)将UUID转为字节序可排序格式，并建了前缀索引（如id BINARY(16) PRIMARY KEY） - 接受主键占用更多存储、备份更慢、pt-table-checksum校验更耗时
现实中，95% 的 OLTP 场景下，坚持用 BIGINT UNSIGNED AUTO_INCREMENT 并预留好分库分表路由字段，比强行“去自增”稳妥得多。最容易被忽略的是：自增不是瓶颈，设计不当的二级索引、缺失 NOT NULL 约束、或未设置合适的 innodb_autoinc_lock_mode 才真拖慢写入。
