--force可跳过重复主键、外键或唯一键等约束错误并继续执行，但不跳过语法错误，且需检查restore.err日志验证跳过项；GTID模式下从库跳过须用SET GTID_NEXT注入空事务，非GTID模式可用sql_slave_skip_counter。
mysql 命令行还原时用 --force 跳过约束类错误
本地执行 mysql 导入 SQL 文件中断，多数是重复主键（1062）、外键冲突（1452）或唯一键冲突导致的——这类错误 --force 可跳过，且无需改服务端配置。
它让客户端忽略报错并继续读取下一行 SQL，但不会跳过语法错误（如 Unknown column 'x' in 'field list'），也不会修复语义断裂（比如跳过一条 INSERT 后，后续依赖该记录的 UPDATE 仍会失败）。
- 命令示例：
mysql -u root -p --force mydb restore.err -
restore.err必须检查：里面会记录所有被跳过的错误（含错误码、SQL 行号），不能只看是否“跑完了” - 该参数只影响客户端行为，不改变服务端
sql_mode或复制状态，还原后从库也不会自动同步这些跳过的操作
主从复制中断时跳过事务：先分清 GTID 是否启用
从库 SQL 线程停住（Slave_SQL_Running: No），错误码为 1062/1032/1410 等，必须先查 gtid_mode，否则选错方法会报错或无效。
执行 SHOW VARIABLES LIKE 'gtid_mode';，若结果为 ON，则 SET GLOBAL sql_slave_skip_counter = 1 直接报错 ERROR 1791 (HY000)，这条路走不通。
- GTID 启用时：必须用
SET GTID_NEXT = 'xxx:nnn'; BEGIN; COMMIT;插入空事务，再SET GTID_NEXT = 'AUTOMATIC'; START REPLICA; - GTID 未启用时：可安全用
STOP REPLICA; SET GLOBAL sql_slave_skip_counter = 1; START REPLICA; - 切勿在配置文件里写
slave_skip_errors = 1062来“一劳永逸”——它只对从库 SQL 线程生效，且掩盖问题，容易导致主从数据持续偏离
事务内批量操作需主动容错，不能依赖全局开关
想在存储过程或应用逻辑中批量更新/插入时跳过个别失败项，MySQL 没有“整个事务忽略错误”的开关。必须把容错逻辑下沉到每条语句级。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
INSERT IGNORE 和 INSERT ... ON DUPLICATE KEY UPDATE 只对单条语句起作用；DECLARE CONTINUE HANDLER FOR SQLEXCEPTION 可捕获错误并继续循环，但无法回滚已成功执行的前几条语句。
- 适合场景：清洗导入、补数脚本、非关键字段批量更新
- 不适合场景：强一致性要求的金融类事务（如扣款+记账必须原子）
- 风险点：
INSERT IGNORE对NOT NULL冲突也只发 warning，可能静默丢数据，建议配合SHOW WARNINGS;检查
跳过不是恢复，中断后必须验证数据完整性
无论用 --force 还是 sql_slave_skip_counter，跳过都只是让流程“跑下去”，不代表数据正确。尤其是主从跳过，跳过的那条事务在从库永远缺失。
常见疏漏点：
- 还原后没比对表行数、校验和（如
CHECKSUM TABLE t1;） - 从库跳过事务后，没用
mysqldump --single-transaction导出关键表与主库比对 - 误以为
--force能处理CREATE TABLE IF NOT EXISTS失败——其实它不能跳过语法错误，遇到Unknown storage engine 'rocksdb'仍会中断
