--force对坏块完全无效，因其仅捕获SQL层错误（如权限不足、视图失效），而InnoDB物理坏块（页校验失败、tablespace缺失）触发内核级I/O异常致mysqldump崩溃退出；需先筛出可访问表再dump，或启用innodb_force_recovery临时启动后导出。
mysqldump --force 为什么对坏块完全无效
--force 只捕获 SQL 层错误（如权限不足、视图定义失效、SELECT 报错），遇到 InnoDB 物理坏块（页校验失败、tablespace is missing、Can't find file './db/t.frm'）时，mysqldump 会直接崩溃退出，连完整错误码都可能没输出。根本原因是：坏块让 MySQL server 在执行 SELECT * FROM t LIMIT 1 时触发内核级 I/O 异常，进程被信号终止，--force 根本来不及介入。
先筛出可访问表，再逐个 dump
核心思路是绕过 mysqldump --all-databases 的自动枚举逻辑，改用可控的表发现 + 可读性验证流程。前提是 MySQL 还能连上、information_schema 基本可用。
- 用
SELECT table_name FROM information_schema.tables WHERE table_schema = 'mydb'获取全量表名 - 对每个表执行轻量探测：
SELECT 1 FROM mydb.$t 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)；若表名含特殊字符（如短横线、空格），需用printf '%q ' $t转义
innodb_force_recovery 是临时读取开关，不是 dump 保险丝
当坏块严重到 MySQL 启动失败或 SHOW TABLES 都报错时，必须启用 innodb_force_recovery 让服务“勉强起来”。但它不保证 mysqldump 就能顺利跑完：
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
- 级别 1–3：允许
SELECT，但mysqldump默认会尝试获取元数据锁或统计信息，仍可能中止 - 级别 4–6：禁止写操作，且部分内部函数被禁用，
mysqldump --single-transaction可能因无法开启一致性快照而失败 - 实操建议：启动时加
--skip-grant-tables --innodb-read-only，再用mysqldump --no-create-info --skip-triggers纯数据导出，减少元数据依赖
真正不可恢复时，别在原实例上硬扛
如果 SELECT 1 FROM t LIMIT 1 卡死、超时，或 mysqldump 导出中途报 ERROR 2013 (HY000) 或 Got error -1 from storage engine，说明该表所在 .ibd 文件区域已无法稳定读取。此时继续重试只会加剧磁盘压力，甚至扩大坏块范围。
更稳妥的做法是：立即对整个数据目录做 ddrescue 镜像，然后在镜像上尝试恢复——因为 ddrescue 会跳过坏扇区并记录日志，后续可多次重试读取残存数据。原实例上任何 ALTER、OPTIMIZE 或强制 DROP 操作，都可能让尚存的页面彻底消失。
