使用 --force 参数可使 mysql 命令行导入时跳过重复主键或唯一键冲突（如 ERROR 1062），打印警告并继续执行；但需配合 mysql 命令而非 mysqldump，且不适用于所有版本的 IF NOT EXISTS 语法。
mysql 命令行导入时跳过重复主键或唯一键冲突
直接加 --force 参数就能让 mysql 在遇到 error 1062 (23000): duplicate entry 这类错误时不中断，继续执行后续语句。它不是“忽略所有错误”，而是对可恢复的 sql 错误（如重复键、无效数据截断）默认打印警告并继续——这点很多人误以为它会静默吞掉错误。
常见错误现象：导入中途卡住，报 ERROR 1062 后整个导入退出；或者用了 --force 却发现没生效，其实是没配对用 mysql 而不是 mysqldump。
mysql --force -u root -p database_name 是正确用法；<code>mysqldump --force是无效的（它只影响导出行为）- 如果 SQL 文件里有
SET FOREIGN_KEY_CHECKS=0;，建议保留，否则外键冲突会绕不过--force -
--force不影响事务行为：如果原 SQL 包含BEGIN/COMMIT，单条语句失败仍可能回滚整个事务（取决于 autocommit 设置）
用 source 命令时如何避免 ERROR 1062 中断
source 是 MySQL 客户端内的命令，本身不支持跳过错误。但它会继承客户端当前的 --force 行为——也就是说，你得在启动 mysql 客户端时就带上 --force，而不是在进入后才执行 source。
使用场景：需要交互式调试导入过程，或文件路径含变量/特殊字符不便用 shell 重定向时。
- 正确启动方式：
mysql --force -u user -p db_name，然后在提示符下输入source /path/to/file.sql; - 错误做法：先运行
mysql -u user -p，再输入source——此时没开--force，照样中断 -
source不解析 SQL 注释里的配置指令，别指望写--force在 SQL 文件开头起作用
my.cnf 配置文件里不能设 skip-error 或 ignore-duplicate
MySQL 服务端配置文件（my.cnf 或 my.ini）里没有类似 skip-error=1062 的选项。这类错误处理逻辑只存在于客户端工具层面，服务端严格遵循 SQL 标准：语句出错就报错，不提供“全局忽略”开关。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
容易踩的坑：网上有些过时资料提到 sql_mode=IGNORE_SPACE 或自定义 init_connect，这些和跳过重复键完全无关；还有人试图改 max_error_count，但它只控制警告显示数量，不影响执行流。
- 服务端唯一相关配置是
sql_mode中的STRICT_TRANS_TABLES——关掉它能让某些隐式转换不报错，但对ERROR 1062无效 - 想“服务端统一处理”，只能换方案：比如用存储过程包装插入逻辑，捕获
SQLSTATE '23000'后CONTINUE，但这和导入无关 - 配置文件能做的极限是：通过
[client]段预设--force，例如：[client] force
，这样每次调用mysql都自动启用
真正需要忽略多种错误时，用 sed 或 awk 预处理 SQL 文件
当不仅要跳过重复键，还要过滤掉 DROP TABLE IF EXISTS 报错、视图创建失败、函数已存在等杂项错误时，--force 就不够用了——它只保底，不分类。
这时最可控的做法是提前清理 SQL 文件，而不是依赖运行时机制。
- 删除所有
DROP语句：sed '/^DROP/d' dump.sql > clean.sql - 跳过创建已存在对象的错误：把
CREATE TABLE替成CREATE TABLE IF NOT EXISTS，但注意这不适用于所有版本（5.7+ 支持，5.6 不支持IF NOT EXISTS对索引） - 用
grep -v "ERROR 1452"没用——那是日志输出，不是 SQL 文件内容；预处理只能针对 SQL 文本本身
复杂点在于：不同 MySQL 版本对语法兼容性要求不同，比如 IF NOT EXISTS 在视图、存储过程里支持时间不一；还有字符集声明、分区语法等，一旦删错可能导致数据不一致。所以预处理适合明确知道错误来源的场景，不适合无脑套用。
