mysqlcheck无法修复文件系统级损坏，仅能处理存储引擎层逻辑错误；实操需先停写入、确认损坏类型、谨慎使用innodb_force_recovery，必要时用strings/grep从磁盘镜像中提取残留文本数据。
直接用 mysqlcheck 修不了的表，大概率是文件系统级损坏
MySQL 自带的 mysqlcheck 或 REPAIR TABLE 只能处理存储引擎层的逻辑损坏（比如索引页错位、B+树断裂），对 ibd 文件被截断、frm 文件丢失、或整个目录被误删/覆盖这类文件系统问题完全无效。这时候不是 MySQL “坏了”，而是它根本读不到完整数据块——就像你拿一张撕掉一半的身份证去刷闸机，机器不认，不是闸机故障。
实操建议：
- 立刻停止写入：
mysqld进程还在跑就关掉，避免进一步覆盖磁盘空闲区 - 别在原盘操作恢复命令：所有修复动作必须在只读挂载的备份镜像或 dd 出来的磁盘副本上进行
- 先确认损坏类型：用
file /var/lib/mysql/dbname/table.ibd看是否报data而非MySQL InnoDB data file；用ls -l检查ibd大小是否异常（比如突然变成 0 或 16KB）
innodb_force_recovery 不是万能开关，值设太高会跳过关键校验
这个配置项本质是让 InnoDB 在启动时跳过某些崩溃恢复阶段，强行把表“拽”出来。但它不是越大力越有效——设成 6 会跳过事务回滚和 undo 日志解析，可能导出脏数据甚至主键冲突；设成 1 又常卡在 buffer pool 初始化，起不来。
实操建议：
- 从
innodb_force_recovery = 1开始试，每次只加 1，启动后立刻用SELECT COUNT(*)验证能否读行，而不是等 mysqld 完全就绪 - 只要能 SELECT 就立刻
mysqldump：此时不要执行任何 UPDATE/INSERT，dump 命令里加--single-transaction和--skip-triggers避免触发恢复路径 - 如果
=3还起不来，说明ibd文件头或 page 0 已损毁，得换底层工具
用 strings + grep 从裸设备里捞文本字段，比硬啃 InnoDB 格式现实
InnoDB 的页结构复杂，没有完整页头和 checksum 就很难准确定位记录起始位置。但如果你的业务表以 VARCHAR、TEXT 为主，且没加密/压缩，原始字符串很可能还躺在磁盘碎片里——尤其是被删除后未覆写的区域。
实操建议：
- 用
dd if=/dev/sdb2 of=disk.img bs=1M count=5000先复制疑似损坏分区前 5GB（InnoDB 数据通常靠前） - 用
strings disk.img | grep -E '^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}'快速筛邮箱类字段，验证数据残留程度 - 若匹配到有效内容，再用
grep -a -B5 -A5 '关键词' disk.img往前后各抓 5 行上下文，人工拼凑记录边界 - 注意：此法对数字型主键、JSON 字段、二进制 blob 无效，且无法还原索引关系
testdisk 和 photorec 能找回文件，但恢复后不能直接当 ibd 用
这两个工具擅长从文件系统元数据损坏中恢复文件名和大小，但 InnoDB 的 ibd 文件恢复后往往缺失前 384 字节的文件头（含 space id、page size、checksum），MySQL 启动时会报 Tablespace is missing for table 或直接拒绝加载。
实操建议：
- 用
testdisk扫描分区后，优先选 “Undelete” 而非 “Recover”，前者尝试复原原文件系统指针，后者只是按文件签名找数据块 - 恢复出的
.ibd文件必须用hexdump -C -n 512 recovered.ibd检查开头是否为78 7c 00 00（InnoDB page 0 magic）；如果不是，基本只能当原始字节流处理 - 真要硬修 header，得用
dd把正常表的前 512 字节bs=512 count=1替换过去，但 space id 必须和目标表一致，否则导入会报tablespace mismatch
最麻烦的点从来不是技术动作本身，而是搞不清损坏发生在哪一层：是 ext4 journal 损坏导致 ibd 元数据错乱，还是 SSD 主控掉电导致某个 page 写了一半，又或是 LVM 快照机制把旧块覆盖了——每种情况对应的取证路径和修复窗口都差很远。动手前多看两眼 dmesg | tail 和 journalctl -u mysql --since "2 hours ago"，比盲目试参数有用得多。
