ERROR 1062主键冲突源于导入数据含已有id值而AUTO_INCREMENT未重置；应优先用INSERT IGNORE或ON DUPLICATE KEY UPDATE，或导出时加--no-create-info配合脚本删id字段，导入前执行ALTER TABLE ... AUTO_INCREMENT = N（N需大于MAX(id)且表为InnoDB）。
MySQL 导入数据时提示 ERROR 1062：Duplicate entry for key 'PRIMARY'
这是最典型的自增主键冲突现象——源数据里已有 id 值（比如从另一库导出的 sql），而目标表的 auto_increment 计数器没重置，导致新插入时撞上已存在的 id。
根本原因不是“不能导入”，而是 MySQL 默认会尝试用原 id 值插入，同时又想维护自增逻辑，两者打架。
- 别急着删
id列或改 SQL 文件——如果业务依赖该字段顺序或外键关联，删了反而断链 - 优先用
INSERT IGNORE或ON DUPLICATE KEY UPDATE控制行为，但前提是导入语句可控（如用程序拼 SQL） - 更通用的做法是临时关闭自增约束：执行
SET FOREIGN_KEY_CHECKS = 0;和SET UNIQUE_CHECKS = 0;（仅限导入前） - 导入完立刻恢复：
SET FOREIGN_KEY_CHECKS = 1;和SET UNIQUE_CHECKS = 1;，否则后续写入可能静默失败
用 mysqldump 导出时跳过自增列值
如果你能控制导出环节，比事后修数据更干净。默认 mysqldump 会把 id 值原样写进 INSERT 语句，只要加一个参数就能让它只导结构+数据，不写主键值。
关键参数是 --skip-insert-values 不对，那是错的；真正有效的是：--no-create-info 配合 --skip-extended-insert 也没用——正确解法是：
- 用
--skip-triggers --skip-routines --skip-events确保不带干扰逻辑 - 核心是加
--complete-insert并手动删掉 INSERT 语句里的id字段（不推荐） - 真正省事的是导出时用
--skip-add-drop-table+--no-autocommit，再配合导入前执行ALTER TABLE tbl_name AUTO_INCREMENT = N; - 但最稳的组合是：
mysqldump --no-create-info --skip-extended-insert db_name tbl_name，然后用 sed 或脚本批量删每行开头的id值（如sed 's/VALUES (.[0-9]*, /VALUES (/g'）
ALTER TABLE ... AUTO_INCREMENT = N 的安全设置时机
很多人导入前设了 AUTO_INCREMENT = 1000，结果发现新插入还是从 1 开始——因为这个值只在「下一次插入无指定主键时」生效，且必须大于当前最大 id。
执行前务必确认两件事：
- 查当前最大值：
SELECT MAX(id) FROM tbl_name;，设的N至少要比它大 1 - 表必须是 InnoDB；MyISAM 表的
AUTO_INCREMENT值重启后可能重置，不可靠 - 执行
ALTER TABLE会锁表（尤其大表），线上环境避开高峰 - 如果表有大量删除记录，
MAX(id)可能远小于实际已用 ID 范围，此时设太小会导致下次插入冲突，宁可略大勿略小
Python/Pandas 导入 CSV 时绕过自增列
用 pandas.to_sql() 直接写入，如果 CSV 含 id 列，默认会把它当普通字段插进去，撞主键就报错。
解决方法不是删 CSV 文件，而是控制写入行为：
- 读取时跳过
id列：df = pd.read_csv('data.csv').drop(columns=['id']) - 写入时明确指定不写主键：
df.to_sql('tbl_name', con=engine, if_exists='append', index=False, method='multi') - 关键是传
index=False，否则 pandas 会把 DataFrame 行号当index插进去，又撞一次 - 如果数据库表主键确实是
id且设为AUTO_INCREMENT，就别在 DataFrame 里留id列，让 MySQL 自己生成
容易被忽略的是：某些 ORM 或连接池会缓存表结构元信息，改了 AUTO_INCREMENT 值后第一次插入仍可能读旧值，建议执行完 ALTER TABLE 后连上新会话再试。
