ALTER TABLE 修改 AUTO_INCREMENT 仅设定下一条 INSERT 的起始编号，不影响已有数据；全局 auto_increment_increment 控制步长，默认为1，两者共同决定新ID值，设错易致主键冲突。
ALTER TABLE 修改自增步长只影响新插入行
改 auto_increment 值本身不改变已有数据，只是设定下一条 insert 的起始编号。比如当前最大 id 是 100，执行 alter table t auto_increment = 200，下次插入就从 200 开始，但 101–199 这段空缺不会自动填充，也不会触发重排。
常见错误是以为改了就能“压缩”或“重置”ID 序列——其实不能。如果真需要重排 ID，得用 UPDATE + 临时表，但会破坏外键引用和业务逻辑，一般不建议。
- 只对下一次插入生效，不影响历史数据
- 必须大于当前表中最大主键值，否则会被 MySQL 自动修正为
MAX(id) + 1 - 若表为空，设为 1 是安全的；非空时设小了，MySQL 会静默调高，不报错也不警告
全局变量 auto_increment_increment 控制步长大小
这个变量决定每次自增跳多少，默认是 1。设成 2 就变成 1,3,5…；设成 10 就是 1,11,21… 它影响所有后续插入（除非被表级设置覆盖），但**不改变当前已存在的 ID**。
典型使用场景是主从架构中避免主键冲突：主库设 auto_increment_increment = 2、auto_increment_offset = 1，从库设 offset = 2，这样两边生成的 ID 自然错开。
- 修改后仅对新连接生效（除非用
SET GLOBAL） -
SET SESSION auto_increment_increment = 5只影响当前会话，适合临时调试 - 重启 MySQL 后恢复默认值，需写入配置文件
my.cnf才持久化 - InnoDB 表在事务中首次插入时才读取该变量，不是每行都查一次
表级 AUTO_INCREMENT 值与全局步长共同作用
表的 AUTO_INCREMENT 属性（即 ALTER TABLE ... AUTO_INCREMENT = N 设置的值）是“起点”，而全局 auto_increment_increment 是“步长”。两者相加决定下一个 ID：比如起点是 100，步长是 5，那么下一个是 105，再下一个是 110。
容易踩的坑是只调起点不调步长，结果发现 ID 还是按 1 递增；或者反过来，只改步长却忘了起点太小，导致插入时因重复主键失败（例如起点是 3，步长是 5，但已有 ID=8 的记录，下个会生成 8，冲突）。
- 检查当前起点：
SELECT AUTO_INCREMENT FROM information_schema.TABLES WHERE TABLE_SCHEMA='db_name' AND TABLE_NAME='t' - 检查当前步长：
SELECT @@auto_increment_increment - 设起点前务必确认它 > 当前最大 ID，且 ≡ offset (mod increment)，否则可能跳过或撞上已有值
主键冲突错误 ERROR 1062 (23000): Duplicate entry 'X' for key 'PRIMARY' 的真实原因
这个报错常被误认为是“自增卡住了”，其实多数情况是：全局步长和表起点没对齐，或者手动 INSERT 了本该由自增生成的值，导致下一次自增计算出重复 ID。
比如表起点是 100，步长是 5，你手动插了一条 id=105，那下次自增还是算 100+5=105，就撞上了。
- 不要混用
INSERT INTO t (id, ...) VALUES (105, ...)和自增字段 - 用
SHOW CREATE TABLE t看实际起点和引擎类型，MyISAM 和 InnoDB 对起点更新时机不同 - 批量导入时关掉自增：
SET autocommit=0; INSERT ...; ALTER TABLE t AUTO_INCREMENT = 新起点;，但要注意并发风险
真正麻烦的是跨库同步或分库分表后合并数据时的 ID 冲突，这时候靠调步长只能缓解，得配合业务层 ID 生成策略或中间件做映射。
