MySQL 自增主键性能高但需合理配置：设 innodb_autoinc_lock_mode= 2 可缓解高并发锁竞争；ID 空洞属正常设计取舍；新表主键应优先用 UNSIGNED BIGINT；分库分表等场景需结合业务唯一键使用。
MySQL 自增主键本身性能很高，但实际使用中常因配置、用法或业务模式不当，反而引发锁竞争、ID 空洞、插入热点甚至服务瓶颈。关键不在“用不用自增”，而在“怎么用”。
高并发下的锁竞争问题
InnoDB 对自增 ID 的分配默认采用表级 AUTO_INC 锁（尤其在 innodb_autoinc_lock_mode = 0 或 1 时），每次 INSERT 都要串行获取锁，严重限制写入吞吐。这在批量导入、秒杀下单等场景尤为明显。
- 推荐将 innodb_autoinc_lock_mode 设置为 2（交错模式）：INSERT … SELECT、REPLACE、LOAD DATA 等语句不再阻塞普通 INSERT，大幅提升并发能力
- 注意副作用：该模式下 ID 不再严格按事务提交顺序分配，可能出现“小范围跳跃”，但 不破坏唯一性与单调递增性
- 确保 binlog_format = ROW，避免主从不一致
ID 空洞不是 bug，而是设计取舍
自增 ID 跳号（如插入后回滚、批量预分配失败、显式指定大值）是正常行为，背后是性能与一致性的权衡——宁可浪费 ID，也不愿加锁回退或查表重算。
- 事务回滚后 ID 不回收：已分配即失效，下一条插入直接 +1
- 批量插入（如 INSERT INTO t SELECT …）会预申请一段 ID，未用完部分直接丢弃
- 手动执行 INSERT INTO t(id, …) VALUES(1000, …) 后，计数器自动更新为 1001，后续插入跳过中间值
只要业务不依赖“连续 ID”做分页、导出或对外展示，这类空洞完全可接受。
数据类型与容量必须前置规划
INT(11) 有符号最大值是 2147483647，按每天 10 万新增记录，约 58 年就会溢出；若含删除 + 跳号，实际寿命更短。线上表一旦 ID 溢出，插入将直接报错。
- 新表主键优先选用 UNSIGNED BIGINT：理论支持 922 万亿条记录，满足绝大多数中长期业务需求
- 避免后期 ALTER TABLE 修改主键类型——涉及全表重建，风险高、耗时长
- 对已有接近上限的 INT 表，可通过 ALTER TABLE t MODIFY id BIGINT UNSIGNED AUTO_INCREMENT 升级（需停写或低峰操作）
不是所有场景都适合自增主键
当业务需要全局唯一、无规律、可离线生成或跨库合并时，自增 ID 天然受限：
- 分库分表后，各分片 ID 易冲突，需额外协调（如设置不同起始值 + 步长）
- 微服务多语言环境下，数据库不再是唯一写入入口，应用层需统一 ID 生成逻辑
- 敏感系统要求 ID 不可预测（防遍历），自增序列极易被推测
此时建议组合策略：表内仍用自增 ID 作聚簇索引提升写入性能，同时增加一个 业务唯一键（如 biz_no） 用于关联、查询和对外暴露。
