必须配对设置auto_increment_increment和auto_increment_offset，单设offset无效；因offset仅定起点、increment才定间隔，二者绑定才生成不重叠序列，如increment=2时offset=1→1,3,5…，offset=2→2,4,6…。
必须配对设置 auto_increment_increment 和 auto_increment_offset，否则单改一个参数毫无作用——这是绝大多数人踩坑的根源。
为什么只改 auto_increment_offset 会继续报 1062 错误
很多人在 my.cnf 里加了 auto_increment_offset = 2 就以为 ID 不会撞了，结果一写就报 Duplicate entry 'X' for key 'PRIMARY'。原因很直接：offset 只决定第一个自增值，后续仍按默认步长 +1 递增。如果主从都设 offset = 1、increment = 1，两边都会生成 1、2、3……同步时必然冲突。
关键逻辑是：offset 定起点，increment 定间隔，二者必须绑定生效。
- 双节点场景：统一设
auto_increment_increment = 2，主库offset = 1（生成 1,3,5…），从库offset = 2（生成 2,4,6…） - 三节点双主：设
increment = 3，各节点offset分别为 1/2/3，且必须落在 1 到increment范围内；超出范围 MySQL 启动时会静默重置为 1 - 配置必须写进
my.cnf并重启生效；SET GLOBAL只影响新连接，复制线程可能仍在用旧值
主从切换后 AUTO_INCREMENT 值不更新，立刻报错
从库升主后报 1062，不是“同步延迟”导致的，而是 MySQL 启动时用 SELECT MAX(id) + 1 初始化该值（5.7 及之前），它不读 binlog，也不看对方状态，所以新主库的计数器很可能远小于旧主库已分配出的最大 ID。
必须手动校准：
- 在目标从库（即将升主）上执行：
SELECT MAX(id) FROM tbl_name; - 取结果 +1，设为新值：
ALTER TABLE tbl_name AUTO_INCREMENT = N;（N必须大于当前所有节点该表的最大 ID） - 确认生效：
SHOW CREATE TABLE tbl_name;查看AUTO_INCREMENT字段是否已更新 - 如果应用有跨库写入历史，得先查所有节点的
MAX(id)，取最大值再 +1，不能只看本机
mysqldump 导入后 AUTO_INCREMENT 没对齐怎么办
导入完立刻插入报 ERROR 1062，大概率是导出文件末尾的 ALTER TABLE `t` AUTO_INCREMENT=12345; 没执行成功。常见原因包括用了 --force 参数跳过错误、工具过滤了 ALTER 语句、或导出时加了 --skip-auto-increment。
快速验证与修复：
- 打开导出 SQL 文件，搜索
AUTO_INCREMENT=，确认该行存在且未被注释 - 若缺失，手动补上：
ALTER TABLE your_table AUTO_INCREMENT = 100001;（前提是SELECT MAX(id) FROM your_table结果确为 100000） - 注意：这个语句必须在导入完成、表结构建好之后立即执行，不能放在导入过程中
GTID 模式下遇到 1062，跳过操作极易翻车
执行 SHOW VARIABLES LIKE 'gtid_mode'; 返回 ON，就进入 GTID 模式。此时严禁用 SET GLOBAL sql_slave_skip_counter = 1，会直接报错并导致复制永久断裂。
唯一合法方式是注入空事务，步骤缺一不可：
- 先停 SQL 线程：
STOP SLAVE SQL_THREAD; - 查出错事务 GTID（从
SHOW SLAVE STATUS\G的Last_SQL_Error或Executed_Gtid_Set差集中提取） - 严格执行：
SET GTID_NEXT='xxx:yyy'; BEGIN; COMMIT; - 重置并启动：
SET GTID_NEXT='AUTOMATIC'; START SLAVE; - 抄错一位字符、漏掉
BEGIN; COMMIT;、或在COMMIT前断开连接，都会让 GTID 状态永久错乱——此时重建从库是唯一选择
真正容易被忽略的是：跳过只是临时止血，不查源头（比如误写从库、应用双写、或 REPLACE INTO 导致主从 AUTO_INCREMENT 计数器不同步），下一次 1062 几乎必然重现。
