alter table ... auto_increment=n仅在表为空或n严格大于当前最大id时生效，否则mysql静默修正为max(id)+1；truncate可强制重置计数器，delete则不能。
ALTER TABLE ... AUTO_INCREMENT= 直接生效但有前提
修改自增ID起始值最常用的方式是 ALTER TABLE table_name AUTO_INCREMENT = N，但它**不会回滚已存在的最大ID**。比如表里已有ID为 1、2、3、5 的记录，当前 AUTO_INCREMENT 是 6，你执行 ALTER TABLE t AUTO_INCREMENT = 4，下一条插入仍会用 6（因为 MySQL 会自动取 MAX(id) + 1 和你指定值的较大者）。
真正生效的条件只有两个：表为空，或你设的值严格大于当前最大ID。否则语句执行成功但实际无效果。
- 检查当前最大ID：
SELECT MAX(id) FROM table_name - 确认当前AUTO_INCREMENT值：
SHOW CREATE TABLE table_name（看末尾的AUTO_INCREMENT=xxx） - 若想强制覆盖（如清空后重置），先
TRUNCATE TABLE table_name，再ALTER TABLE ... AUTO_INCREMENT=1（TRUNCATE会重置计数器，DELETE不会）
INSERT ... SELECT 或 REPLACE INTO 可能绕过 AUTO_INCREMENT 控制
当用 INSERT INTO t (id, name) VALUES (100, 'x') 显式插入ID时，MySQL允许跳过自增逻辑——这本身不是bug，但容易导致后续自增行为“意外”：
- 如果插入的ID ≥ 当前
AUTO_INCREMENT值，MySQL会自动把AUTO_INCREMENT更新为该ID + 1 - 例如当前
AUTO_INCREMENT=5，你执行INSERT INTO t (id) VALUES (10)，之后新记录ID就从 11 开始 -
REPLACE INTO和INSERT ... ON DUPLICATE KEY UPDATE同样会触发这个“自动抬升”逻辑
所以，如果你手动设了 AUTO_INCREMENT=100，又不小心插入了一条 id=200 的记录，下次自增就变成 201 —— 这个变化不会报错，也难被监控到。
主从复制环境下修改需格外谨慎
在主从架构中，ALTER TABLE ... AUTO_INCREMENT 是 DDL 语句，会写入 binlog 并同步到从库。但问题在于：如果主库和从库当前 MAX(id) 不一致（比如从库延迟或曾跳过某些事务），执行该语句后，从库可能因ID冲突而中断复制（错误如 ERROR 1062 (23000): Duplicate entry 'X' for key 'PRIMARY'）。
- 操作前务必确认主从
MAX(id)一致：SELECT MAX(id) FROM table_name在主从上分别执行 - 避免在业务高峰期执行；建议配合
STOP SLAVE+ 手动校验 +START SLAVE流程 - 使用
innodb_autoinc_lock_mode=2（交错模式）时，批量插入可能生成非连续ID，进一步加大主从ID偏移风险
使用 SET INSERT_METHOD=NO 禁用自增不现实
有人查文档看到 INSERT_METHOD 分区表参数，误以为能关掉自增。实际上：INSERT_METHOD 仅用于 UNION 分区表向哪个子分区插入数据，对普通表无效；MySQL **没有运行时开关可禁用或暂停自增行为**。
如果真需要完全控制ID生成，唯一可靠方式是：去掉 AUTO_INCREMENT 属性，改由应用层或数据库序列（如通过 SELECT @next_id := MAX(id)+1 FROM t FOR UPDATE + 插入）管理——但这会引入锁竞争和并发风险，一般只在特殊场景（如金融单号）才考虑。
多数情况下，老老实实算好 MAX(id) + 1 再设 AUTO_INCREMENT，比试图绕过它更安全。尤其注意：InnoDB 表的自增值是内存中的，重启后会重新读取 MAX(id)+1，所以不能依赖“重启保留设置”。
