先查SHOW TABLE STATUS和SELECT MAX(id)，若后者≥前者Auto_increment值，说明自增错位，是ERROR 1062根因；需设Auto_increment为MAX(id)+1，并检查双主offset/increment配对、序列状态及log_slave_updates等。
先查 SHOW TABLE STATUS 和 SELECT MAX(id)，两者不一致就是根因——不是数据重复，而是自增值没对齐。
怎么看当前自增状态是否错位
迁移后插入就报 ERROR 1062 (23000): Duplicate entry 'X' for key 'PRIMARY'，大概率是表的 Auto_increment 值小于或等于当前最大主键值。
- 执行
SHOW TABLE STATUS LIKE 'your_table'，记下Auto_increment字段值（比如是100） - 再执行
SELECT MAX(id) FROM your_table（比如返回999） - 如果
MAX(id) >= Auto_increment，说明下次INSERT会尝试插100，必然撞上已存在的999甚至更小的值 - 注意：
Auto_increment是「下一次无显式指定主键时将用的值」，不是「当前最大值 + 1」的自动推导结果
为什么 mysqldump 导入后经常出这个问题
导出 SQL 文件里那句 ALTER TABLE `t` AUTO_INCREMENT=12345; 很可能根本没执行成功。
- 常见原因：用了
--force参数跳过错误、工具过滤了ALTER语句、导出时加了--skip-auto-increment - 快速验证：打开 SQL 文件，搜索
AUTO_INCREMENT=，确认该行存在且未被注释 - 若缺失，不能直接补一句
ALTER TABLE t AUTO_INCREMENT = 12345就完事——必须先查SELECT MAX(id) FROM t，设的值要严格大于它 - 设小了 MySQL 5.7+ 会静默忽略，不报错也不生效
双主/多主环境要额外盯住三个参数
只改 auto_increment_offset 没用，必须和 auto_increment_increment 绑定生效，且复制链不能断。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 连上每个节点，执行
SELECT @@auto_increment_increment, @@auto_increment_offset—— 必须看到预期配对（如双主 A 是2/1，B 是2/2） - 漏配
innodb_autoinc_lock_mode = 0：批量插入（INSERT SELECT等）可能跳号，后续 INSERT 就撞 - 漏配
log_slave_updates = ON：本机 relay log 的变更不写 binlog，双向复制断裂，GTID 校验全失效 - 漏配唯一
server-id：A→B→A 的事件会被重复执行，ID 冲突只是表象，数据逻辑早已错乱
金仓（KingbaseES）迁移场景要检查序列状态
MySQL 的 AUTO_INCREMENT 在金仓里靠 SEQUENCE 模拟，迁移工具 KDTS 很容易漏初始化序列值。
- 执行
SELECT sequence_name, last_value FROM information_schema.sequences WHERE sequence_name LIKE '%your_table%' - 查到的
last_value必须 ≥ 目标表当前最大id；否则下一次nextval()就会生成一个已存在的 ID - 修复方式：用
ALTER SEQUENCE seq_name RESTART WITH N（N > 当前最大 id） - 注意：MySQL 导出的数据里没有序列信息，KDTS 日志中若出现
"duplicate key value violates unique constraint"，基本可锁定是序列没对齐
真正麻烦的不是查不到问题，而是查到了却只修了表级 AUTO_INCREMENT，忘了节点间 offset/increment 配对、忘了序列、忘了 log_slave_updates——这些点只要漏一个，重启服务或流量一上来，冲突立马复现。
