只设auto_increment_offset会失效，因为offset仅决定首个自增值，后续仍按默认步长+1递增；必须与auto_increment_increment配对设置并重启生效，否则两节点均生成1、2、3…导致主键冲突。
为什么只设 auto_increment_offset 会失效
很多人在 my.cnf 里加了 auto_increment_offset = 2 就以为 ID 不会撞，结果一写就报 Duplicate entry '1' for key 'PRIMARY'。这是因为 offset 只管第一个自增值，后续仍按默认步长 +1 递增。两台机器都设 offset = 1、increment = 1，都会生成 1、2、3……同步时必然冲突。
真正起作用的是两个参数的绑定关系：offset 定起点，increment 定间隔，缺一不可。
- 双节点主从：主库设
auto_increment_increment = 2+auto_increment_offset = 1（生成 1,3,5…）；从库设相同increment+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） - 注意：这个值必须严格大于当前表中所有已有 ID，否则下次插入仍会撞
什么时候该放弃自增 ID 改用全局唯一标识
当你的架构演进到多写、分片、跨数据中心或需要强一致迁移时，硬靠 auto_increment_increment 和 offset 配对已经扛不住了。比如双主写入+定时合并、云上弹性扩缩容、或混合部署（MySQL + TiDB + PG），自增列的中心化依赖会成为瓶颈和故障点。
更可持续的做法是把 ID 生成逻辑移出数据库：
- 应用层用雪花算法（Snowflake）或
UUID_SHORT()生成 64 位整数 ID，避免主键冲突也减少锁竞争 - 用
INSERT IGNORE或ON DUPLICATE KEY UPDATE做兜底，但仅限于幂等写入场景，不能替代 ID 设计 - 如果必须保留自增语义，至少把主键和业务 ID 解耦：主键仍自增，另加一个
business_id字段存全局唯一值，并建唯一索引
最常被忽略的一点是：配置改了、SQL 写了、dump 导了，但没人检查 SHOW CREATE TABLE 输出里的 AUTO_INCREMENT 实际值是否真变了——它不显示在 DESCRIBE 里，也不反映在 SELECT 结果中，只能靠这条命令确认。
