mysqldump 加 --insert-ignore 参数可直接生成 INSERT IGNORE 语句，避免主键冲突报错；该参数全局生效、不支持按表控制，MySQL 5.7+ 支持，但 8.0.21 前在 STRICT 模式下可能仍报错。
mysqldump 怎么加 --insert-ignore 参数
导出时直接生成 insert ignore 语句，核心就是让 mysqldump 自己加这个关键字，而不是靠后续文本替换。必须用 --insert-ignore，别写成 --ignore 或 --replace —— 后者会生成 replace into，语义完全不同，可能意外删数据。
常见错误是漏掉这个参数，结果导出全是普通 INSERT，导入时一撞主键就报错 ERROR 1062 (23000): Duplicate entry。
mysqldump --insert-ignore -u root -p db_name table_name > dump.sql- 如果导出整个库，所有表都会统一加
INSERT IGNORE - 不支持按表单独开关，整条命令生效
- MySQL 5.7+ 均支持，但 MySQL 8.0.21 之前对
INSERT IGNORE的严格模式兼容性略差，遇到STRICT_TRANS_TABLES开启时仍可能报错
导出后手动替换 INSERT INTO 安不安全
能避免就别手动替换。表面看只是把 INSERT INTO 换成 INSERT IGNORE INTO，但实际有坑：
- dump 文件里可能有注释、存储过程、视图定义，里面也含
INSERT INTO字样，盲目全局替换会污染非数据语句 - 有些
INSERT是带/*!40000 ... */条件注释的，改错位置会导致语法错误 - 大文件（>1GB）用
sed或编辑器替换容易卡死或丢内容 - 如果 dump 含
CREATE TABLE且没加--no-create-info，替换还可能误动建表语句里的字段名（比如字段叫insert_into_time）
为什么不用 ON DUPLICATE KEY UPDATE 替代
INSERT IGNORE 和 ON DUPLICATE KEY UPDATE 行为差异很大，不能混用：
-
INSERT IGNORE：冲突时跳过整行，不做任何更新，也不触发警告以外的反馈 -
ON DUPLICATE KEY UPDATE：冲突时执行指定字段更新，适合“存在则更新，不存在则插入”场景 -
mysqldump不支持原生导出ON DUPLICATE KEY UPDATE语句，硬加需要 post-process，复杂度远超--insert-ignore - 若业务依赖冲突后更新某些时间戳字段，
--insert-ignore就不合适，得换方案（比如先DELETE再导入，或用LOAD DATA INFILE配合IGNORE）
导入时还要注意哪些兼容性细节
即使导出了 INSERT IGNORE，导入时仍可能失败，关键在服务端配置：
- 确认目标库的
sql_mode不含STRICT_TRANS_TABLES或STRICT_ALL_TABLES，否则字段类型不匹配（如空字符串插数字字段）也会被当成错误拦截，IGNORE失效 - 如果源库和目标库字符集不同（比如源是
utf8mb4，目标是latin1），即使加了IGNORE，也可能因乱码导致主键值变化，引发意料外冲突 - 导入前建议先执行
SET unique_checks=0; SET foreign_key_checks=0;，否则外键约束或唯一索引重建过程可能中断导入 -
mysql客户端默认开启autocommit，每条INSERT IGNORE独立提交，大数据量时极慢；可加--init-command="SET autocommit=0"再配合COMMIT手动控制
真正麻烦的从来不是加个 --insert-ignore，而是导出环境和服务端 SQL 模式、字符集、约束状态这些隐性条件是否对齐。漏查一项，就可能让 IGNORE 形同虚设。
