myisamchk和innochecksum均无法修复mysqldump生成的.sql备份文件：前者仅适用于MyISAM物理文件（.MYI/.MYD），对SQL文本报错；后者仅为InnoDB页校验工具，不支持SQL格式且无修复功能；修复.sql文件需用文本处理截断坏段并配合--force导入。
myisamchk 和 innochecksum 都不能修复 MySQL 备份文件——如果你手头的是 mysqldump 生成的 .sql 文件，这两个工具根本不会起作用。
myisamchk 对 .sql 文件完全无效
myisamchk 只能处理 MyISAM 引擎的物理表文件（.MYI 索引 + .MYD 数据），它读取的是二进制结构，不是 SQL 文本。
运行 myisamchk backup.sql 必然报错：error: 'backup.sql' is not a MyISAM table。
常见误用场景包括：
- 把
mysqldump导出的文本备份当成 MyISAM 表文件传给myisamchk - 在没停 MySQL 的情况下对正在被写的
.MYI文件执行myisamchk，导致校验失败或服务崩溃 - 对 InnoDB 表的
.ibd文件强行运行myisamchk，输出乱码且无任何修复效果
innochecksum 不是修复工具，只是校验器
innochecksum 的唯一功能是计算并比对 InnoDB 页的 checksum 值，用于判断单个 .ibd 或 ibdata1 文件是否发生静默损坏（比如磁盘位翻转）。它不修改、不重建、不跳过错误。
- 运行
innochecksum table.ibd报page checksum mismatch，只说明某页损坏，但不告诉你哪条记录丢了、怎么补 - 它对
.sql、.sql.gz、.xb目录等备份格式完全不识别 - 即使校验通过，也不能保证
.ibd能被 MySQL 正常加载——页头损坏、space id 不匹配、LSN 断裂等问题它检测不到
真正该用什么修 SQL 备份文件？
SQL 备份本质是 UTF-8 文本，修复思路是“截断坏段 + 绕过语法错误 + 补关键符号”，不是调数据库引擎工具。
- 用
head -n 200000 backup.sql | tail -n 50查看最后完整语句位置，再用sed -n '1,200000p' backup.sql > fixed.sql截断 - 导入时必须加
--force：mysql -u root -p --force dbname ，否则遇到 <code>ERROR 1064就中断 - 手动检查末尾：缺
COMMIT;就补上；最后一行是半截INSERT INTO ... VALUES (就整行删掉 - 对大表单独提取：
sed -n '/^CREATE TABLE `users`/,/^-- Table structure for table `/p' backup.sql > users.sql
物理备份（.ibd / xb）损坏才轮到 innochecksum + innodb_force_recovery
只有当你面对的是 XtraBackup 生成的二进制目录（含 ibdata1、test/t1.ibd），且 innobackupex --apply-log 失败时，innochecksum 才有前置诊断价值。
- 先跑
innochecksum ibdata1和关键.ibd，确认哪些文件页级损坏 - 若仅少量页损坏，可尝试设
innodb_force_recovery = 1启动 MySQL，立刻mysqldump导出 - 若
innochecksum报大量 mismatch，或innodb_force_recovery = 6仍无法启动，说明文件头或 space header 已毁，此时应放弃修复，转向strings + grep拣选明文字段或使用innodb_ruby
真正容易被忽略的一点：修复动作永远不能在原始损坏文件上直接进行。无论用 sed 截断还是 innodb_force_recovery 启动，都必须先 cp 一份副本——原文件一旦被覆盖或写入，残留数据就彻底没了。
