MySQL自增主键不连续不是故障，而是设计使然；真正应做的是停止依赖其连续性，并在必要时安全调整起始值——因事务回滚、唯一键冲突、批量插入等均会预分配ID且不可回收，强行修复反而引发主键冲突或性能下降。
MySQL的AUTO_INCREMENT主键不连续不是故障，也不该“解决”——它本就不是为连续而设计的。真正要做的，是停止依赖连续性，并在必要时安全调整起始值。
为什么ALTER TABLE AUTO_INCREMENT = N经常失效
这条语句只在满足特定条件时才生效：
-
AUTO_INCREMENT值必须大于当前表中MAX(id)，否则会被静默忽略（MySQL 8.0+会发Warning但不报错） - 执行前需确认：
SELECT MAX(id) FROM your_table;和SHOW CREATE TABLE your_table;对比两者，若前者 ≥ 后者中的AUTO_INCREMENT值，则必须重设 - 不能在从库执行：GTID复制下会导致主从自增值错位，同步中断
- 操作期间应加
READ LOCK或停写，避免并发INSERT干扰新值生效
innodb_autoinc_lock_mode=1导致批量插入跳号
这是迁移或大批量导入后出现大段空洞的主因，不是配置错误，而是InnoDB默认的并发优化策略：
- 模式
1（默认）：语句级锁，INSERT INTO t SELECT ...会预分配一段ID（比如申请8个，只用5个），造成断层 - 模式
2：无锁，更高并发，但ID分配更不可预测，且要求binlog_format = ROW - 模式
0：全表锁，能保证严格连续，但性能极差，线上基本不用 - 查当前设置：
SELECT @@innodb_autoinc_lock_mode;；动态修改：SET GLOBAL innodb_autoinc_lock_mode = 1;（注意主从一致性）
事务回滚和唯一键冲突必然消耗ID
这两类操作都会触发ID预分配，且不可回收，属于InnoDB的确定性行为：
- 执行
BEGIN; INSERT INTO t VALUES (NULL, 1, 1); ROLLBACK;后，AUTO_INCREMENT已+1，无法撤销 - 建表含
UNIQUE KEY c(c)，已有(1,1,1)，再插(NULL, 1, 2)报Duplicate entry '1' for key 'c'，但ID仍升至2 - 这种行为与
innodb_autoinc_lock_mode无关——只要用了NULL或未指定主键，就触发预分配 - 业务层若需“可控编号”，应放弃
AUTO_INCREMENT，改用应用层生成（如雪花ID）或显式指定主键值
MySQL重启后AUTO_INCREMENT变小怎么办
这在MySQL 5.7及更早版本常见，本质是自增值未持久化：
- InnoDB在5.7之前把
AUTO_INCREMENT存在内存里，重启后会扫描表数据，取MAX(id)+1作为新起点 - 所以删光数据后重启，
AUTO_INCREMENT可能从100回落到1（因为MAX(id)变成0） - MySQL 8.0起通过redo log实现持久化，重启不再丢失历史最大值
- 若仍在用5.7，可通过
INSERT一条假数据再DELETE来“锚定”高位值（不推荐），更稳妥的是升级或接受该行为
最危险的操作，是试图用导出-清空-重导入、触发器或变量重赋值等方式“填洞”。这些做法破坏唯一性保障、引发主键冲突、拖慢写入，且治标不治本——空洞本身无害，对连续性的执念才有害。
