恢复时加--force参数会静默跳过错误导致数据丢失，需通过grep查error日志、比对表数量、check table校验及抽样查询验证完整性。
恢复时遇到错误但没报错，数据就悄悄丢了
MySQL执行 SOURCE 或管道导入 SQL 文件时，默认遇到语法错误、表已存在、主键冲突等会中断并报错——但如果你加了 --force 参数（比如 mysql -u root -p --force database_name ），它就会跳过所有错误继续执行。这意味着：某张表因 <code>CREATE TABLE 失败被跳过，后续所有对该表的 INSERT 全部静默失败，最终这个表在库中是空的，而你可能完全没注意到。
常见静默丢失场景包括：
-
ERROR 1050 (42S01): Table 'xxx' already exists→ 加了--force就跳过，后续 INSERT 全部报ERROR 1146被忽略 -
ERROR 1067 (42000): Invalid default value for 'created_at'→ 严格模式下建表失败，整张表结构缺失 -
ERROR 1231 (42000): Variable 'sql_mode' can't be set to the value of 'NO_ZERO_DATE'→ dump 文件头部设置失败，导致后续时间字段插入被截断或转成 0000-00-00
怎么确认恢复过程有没有跳过语句
别靠肉眼扫终端输出。必须让 MySQL 把每一步都记下来：
- 用重定向记录完整执行日志：
mysql -u root -p --force database_name restore.log 2>&1 - 然后立刻检查日志里有没有
ERROR行：grep "ERROR" restore.log | wc -l，非零就说明有跳过 - 重点搜这些关键词：
ERROR 1146（表不存在）、ERROR 1062（主键重复）、ERROR 1064（语法错误） - 对比备份文件里的表数量和恢复后实际表数量：
grep "^CREATE TABLE" backup.sql | wc -lvsmysql -Nse "SELECT COUNT(*) FROM information_schema.tables WHERE table_schema='database_name'"
为什么 mysqldump 导出的文件恢复时会漏数据
不是 dump 文件本身坏了，而是导出时的参数影响了恢复行为：
- 没加
--skip-triggers但目标库权限不足 → 触发器创建失败，后续依赖触发器的逻辑就断了 - 用了
--single-transaction导出，但恢复时目标库是 MyISAM 引擎 →CREATE TABLE ... ENGINE=InnoDB语句失败，整张表建不出来 - 导出时带了
--set-gtid-purged=ON，但恢复库没开 GTID → 开头的SET @@GLOBAL.GTID_PURGED语句报错，如果加了--force，后面所有内容都可能错位执行 - 字符集不一致：dump 文件里写的是
DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci，但目标库 MySQL 5.7 不支持该 collation → 建表失败，INSERT 全部失效
真正有效的验证方式不是“没报错”，而是查数据
恢复完成后，光看 mysql> SHOW TABLES; 是没用的。必须做三件事：
- 对每个关键表，运行
CHECK TABLE <code>table_name;，确认存储引擎层无损坏（尤其 InnoDB 的页校验） - 抽样比对行数：
SELECT COUNT(*) FROM <code>table_name; 和备份前原始值是否一致（可从information_schema.TABLES或上次mysqldump日志里找） - 查几条带业务含义的数据，比如最新一条订单、某个固定用户 ID 的记录是否存在、时间字段是否被截断为
0000-00-00
最容易被忽略的是：恢复脚本里可能包含 USE other_database; 或未加数据库名的 CREATE TABLE，导致部分表建在了错误库中，表面看“恢复成功”，实则数据散落。
