alter table … auto_increment=xxx 不生效的常见原因有三：一是设置值≤当前最大id，mysql静默忽略；二是表为空但曾删光数据，innodb 5.7前重启后重算为1；三是myisam引擎需flush tables或重启才加载新值。
ALTER TABLE … AUTO_INCREMENT=xxx 为什么有时不生效
直接执行 ALTER TABLE t AUTO_INCREMENT = 1000 后插入新行，ID 却还是从 1 开始？常见原因有三个：
- 目标值 ≤ 当前表中最大
id值：MySQL 要求设置的AUTO_INCREMENT值必须严格大于当前最大主键值，否则语句静默忽略（无报错，也不生效） - 表为空但曾插入过数据又被删光：InnoDB 在 5.7 及之前版本重启后会重新扫描
MAX(id)，若表空则设为 1；即使你手动设过 1000，重启后仍可能回退 - 使用了 MyISAM 引擎且未刷新表状态：MyISAM 把自增值存在数据文件里，改完后需执行
FLUSH TABLES或重启 mysqld 才能确保加载
验证是否生效，别只看 SHOW CREATE TABLE 输出里的 AUTO_INCREMENT=xxx —— 那只是“结构定义快照”，实际运行值可能不同。应执行：
SELECT MAX(id) FROM t;
再插入一条 INSERT INTO t (name) VALUES ('test');，查刚插入的 id 值，才是真实起始行为。
重置自增 ID 到最小可用值（比如清空后从 1 开始）
想让表彻底“归零”，不是简单设 AUTO_INCREMENT=1 就行。关键要看你用的是什么清空方式：
-
DELETE FROM t：只删数据，AUTO_INCREMENT不变，下次插入仍是原最大值 +1 -
TRUNCATE TABLE t：重置计数器（等效于删表重建），AUTO_INCREMENT回到 1（或auto_increment_offset设定的初始值） -
DROP TABLE t; CREATE TABLE t (...)：最彻底，完全新建表，自增值从默认 1 开始
注意：TRUNCATE 是 DDL 操作，不可回滚，且要求有 DROP 权限。如果业务不允许中断写入，又必须重置，可考虑先建新表、迁移数据、再原子切换表名。
处理主键冲突时，强行指定 ID 导致后续自增异常
执行 INSERT INTO t (id, name) VALUES (500, 'foo') 后，下一条无 ID 的插入却生成了 id=501，而非预期的 id=1？这是因为 MySQL 的自增计数器更新规则：
- 若插入时显式指定了
id值 X，且 X ≥ 当前计数器值 Y，则计数器立即更新为X + auto_increment_increment（默认为 1） - 哪怕 X 是“跳着填”的（比如当前最大是 10，你插了个 500），计数器也会跳到 501，之后所有隐式插入都从这开始
- 这个行为在事务回滚后依然保留——
INSERT ... VALUES (500)失败或回滚，计数器也不会倒退
所以，不要靠“手动插一个大 ID”来“占位避冲突”。真要绕过冲突，要么用 REPLACE INTO（会触发删除+插入），要么用 INSERT IGNORE（跳过冲突行），但两者都不改变自增计数器逻辑。
MySQL 5.7 和 8.0 在自增值持久化上的关键差异
重启后自增 ID 是否“记得住”，取决于 MySQL 版本和引擎：
- MySQL ≤ 5.7 + InnoDB：自增值只存内存，重启后执行
SELECT MAX(id) FROM t FOR UPDATE重新计算，删掉最大 ID 行再重启，就可能复用旧值（危险！） - MySQL 8.0 + InnoDB：自增值变更写入 redo log，并在 checkpoint 时落盘到系统表
mysql.innodb_table_stats，重启后优先读磁盘值，基本可保证单调递增 - MyISAM（所有版本）：自增值始终保存在数据文件（
.MYD）中，只要文件没损坏，重启不丢失
线上环境若依赖自增 ID 的单调性（比如用作业务流水号、分库分表路由依据），务必确认 MySQL 版本 ≥ 8.0，且不要混用 DELETE + 重启这种组合操作——它在老版本里是隐形炸弹。
