必须配对设置 auto_increment_increment 和 auto_increment_offset 并校准 AUTO_INCREMENT 值，因为 offset 仅决定起始值，increment 决定步长，二者绑定才生效；单设 offset 会导致重复主键，如双节点均设 offset=1、increment=1 时均生成 1,2,3…引发冲突。
必须配对设置 auto_increment_increment 和 auto_increment_offset，并手动校准 AUTO_INCREMENT 值，否则光改配置或只调一个参数都无效。
为什么只改 auto_increment_offset 没用
很多人在 my.cnf 里加了 auto_increment_offset = 2 就以为万事大吉，结果照样报 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
切换后立刻报错，不是因为“同步延迟”，而是新主库的 AUTO_INCREMENT 值仍沿用旧从库状态，而旧主库（现从库）可能已分配出更高 ID。MySQL 启动时用 SELECT MAX(id) + 1 初始化该值（5.7 及之前），不读 binlog，也不看对方状态。
操作步骤：
- 在目标从库（即将升主）上执行：
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） - 注意：
ALTER TABLE AUTO_INCREMENT = N仅在N > MAX(id)时生效，推荐设为MAX(id) + 1；MyISAM 表不适用，大表执行会加写锁
最容易被忽略的三个点
很多团队配了 offset/increment、也做了校准，还是踩坑，往往栽在这三个地方：
-
innodb_autoinc_lock_mode没锁死：双主必须设为0（传统模式），否则并发插入可能绕过锁机制导致跳号 - 云厂商 RDS（如阿里云 MySQL）禁止修改
auto_increment_offset，得换用 UUID 或雪花 ID 替代方案 - 现有应用没加
ON UPDATE CURRENT_TIMESTAMP、没设sql_mode=STRICT_TRANS_TABLES、也没做主键冲突重试逻辑——这些会在AUTO_INCREMENT失控时悄无声息地丢数据
