--force不能跳过InnoDB物理坏块，仅处理SQL逻辑错误；遇坏块时mysqldump会崩溃退出，需先用information_schema筛出可访问表再dump，或启用innodb_force_recovery（从1开始试）临时恢复，严重损坏应改用ibd2sdi等物理层工具。
mysqldump 加 --force 真的能跳过坏表吗
不能直接跳过损坏的表，--force 只让 mysqldump 在遇到 sql 错误（比如权限不足、视图定义失效）时继续导出其他对象，但对 innodb 物理坏块（如页校验失败、tablespace is missing）完全无效——此时 mysqldump 会直接崩溃退出，连错误提示都可能不完整。
常见错误现象：mysqldump: Got error: 1017: Can't find file: './db/t.frm' (errno: 2 - No such file or directory) 或更底层的 ERROR 2013 (HY000) at line XXX: Lost connection to MySQL server during query。
-
--force适合应对逻辑层问题（如某张视图 SELECT 失败），不适合物理损坏 - 真正遇到坏块时，MySQL 服务本身可能已无法正常访问该表，
SHOW TABLES都报错，mysqldump根本拿不到表列表 - 若启用了
innodb_force_recovery > 0，部分坏表可能“临时可读”，但mysqldump默认仍会因元数据不一致而中止
绕过损坏表的实操方案：先筛表再 dump
核心思路是不依赖 mysqldump --all-databases 自动枚举，而是手动构造可导出的表清单，把已知损坏的表排除掉。前提是 MySQL 还能连上、能执行简单查询。
使用场景：服务器仍在运行，mysql 客户端可登录，但个别表 SELECT COUNT(*) 报错或卡死。
- 用
SELECT table_name FROM information_schema.tables WHERE table_schema = 'db_name'获取表名，再逐个SELECT 1 FROM table_name LIMIT 1测试是否可访问 - 脚本化过滤示例（bash）：
mysql -Nse "SELECT table_name FROM information_schema.tables WHERE table_schema='mydb'" | while read t; do mysql -e "SELECT 1 FROM mydb.$t LIMIT 1" >/dev/null 2>&1 && echo $t; done > good_tables.txt
- 然后用
mysqldump mydb $(cat good_tables.txt | xargs)导出——注意表名含特殊字符时需转义，生产环境建议用--skip-extended-insert减少单条语句体积，避免内存溢出
innodb_force_recovery 是救命开关，但有严格限制
当表严重损坏导致 MySQL 启动失败或无法连接时，必须靠 innodb_force_recovery 让服务“勉强起来”，才有机会导出还能读的数据。但它不是万能补丁，级别设高了反而让 dump 更不稳定。
参数差异与风险：innodb_force_recovery 取值 1–6，数值越大恢复力度越激进，但写操作被彻底禁止，且某些级别下 mysqldump 会因无法获取事务信息而报错 ERROR 1712 (HY000): Index xxx is corrupted。
- 从
1开始试：跳过崩溃恢复，通常够用；2禁用主线程，防止脏页刷盘；3跳过事务回滚——此时mysqldump可能导出未提交数据 - 不要一上来就设
6：它会跳过索引构建，导致mysqldump读取主键时触发断言失败，进程直接 SIGSEGV - 配置后必须加
read_only = ON，否则任何写入（包括 dump 过程中的临时表）都会引发未知行为
真正坏块时，mysqldump 不是首选工具
如果 innodb_force_recovery=4 以上仍无法让 mysqldump 完成，说明坏块已深入数据页结构，此时强制 dump 得到的 SQL 很可能包含乱码、截断或语法错误，导入后数据不一致。
更稳妥的做法是切换到物理层工具，绕过 MySQL Server 直接扫描 ibd 文件：
-
ibd2sdi（MySQL 8.0+）可提取表结构定义，即使表损坏也能读出CREATE TABLE语句：ibd2sdi /var/lib/mysql/mydb/t.ibd -o t.sdi
- 第三方工具如
mysqlfrm（已弃用）或Percona Data Recovery Tool for InnoDB可尝试解析页内容，但要求你清楚知道损坏范围和页类型 - 备份恢复链没断的话，优先从最近一次可用的
xtrabackup全备中提取单表——xtrabackup --export生成的.exp文件比 mysqldump 更抗损
坏块位置越靠近表空间头部（比如 space header 或 FSP_HDR 页），越难通过常规手段抢救；这时候导出脚本里写的“忽略错误”基本等于放弃数据一致性。
