不能修sql备份文件——myisamchk和innodb_force_recovery对其完全无效：前者只处理.myi/.myd物理文件，后者仅作用于运行中innodb数据文件；修复需用head/tail/sed截断坏段并配合mysql --force导入。
能修，但不能靠数据库引擎工具——myisamchk 和 innodb_force_recovery 对 SQL 备份文件完全无效。 截断的 backup.sql 是纯文本，修复逻辑只能是“删坏段、补缺位、绕过语法陷阱”，核心靠 head/tail/sed 配合 mysql --force。
为什么 myisamchk 和 innodb_force_recovery 会报错或没用？
myisamchk 只认 .MYI/.MYD 物理文件，对 backup.sql 运行会直接报 'backup.sql' is not a MyISAM table；innodb_force_recovery 是 MySQL 启动参数，只作用于加载中的 ibdata1 或 .ibd，加在 my.cnf 里再导入 SQL 文件，等于没加。
常见误操作包括：
- 对
backup.sql执行myisamchk backup.sql，结果报错退出 - 导入前修改
my.cnf加innodb_force_recovery = 1，重启 MySQL 后再跑mysql -u root -p dbname ，错误照常出现 - 把
xtrabackup的.xb目录当成运行实例去设该参数，参数根本不会加载
怎么定位截断位置并安全截取有效部分？
截断通常发生在末尾，先看最后几十行是否完整：
- 执行
tail -n 50 backup.sql，重点检查：- 最后一行是不是以
;结尾（尤其是COMMIT;、UNLOCK TABLES;） - 有没有半截
INSERT INTO `table` VALUES (开头却没闭合的括号 - 是否缺失
-- Dump completed on这类标记行
- 最后一行是不是以
- 若发现损坏在第 128456 行附近，用
sed -n '1,128455p' backup.sql > fixed.sql截出前段 - 更稳妥的做法：用
head -n 200000 backup.sql | tail -n 100查看倒数第 100 行附近的完整语句结尾，再按该行号截取
导入时如何避免 ERROR 1064 中断？
--force 是唯一能跳过单条语法错误继续执行的开关，但它不输出跳过了什么，必须人工核对：
- 命令必须带
--force：mysql -u root -p --force dbname - 导入后立刻检查终端输出，搜索
ERROR at line或Warning，确认跳过了哪些语句 - 对关键表执行
SELECT COUNT(*)，和原库或备份日志里的行数比对，确认数据量无异常丢失 - 如果只有一张大表损坏严重，可用
sed -n '/^CREATE TABLE `orders`/,/^-- Table structure for table `/p' backup.sql > orders.sql单独提取并修复
最容易被忽略的细节：文件头、编码、扩展名
看似无关，但实际常导致 ERROR 1064 出现在 line 1：
- 用
head -n 5 backup.sql确认开头是-- MySQL dump或CREATE DATABASE，不是乱码或二进制头 - 文件名必须是
.sql后缀，backup.txt或backup.dump会被 shell 或某些脚本误判 - 导入时显式指定字符集：
mysql --default-character-set=utf8mb4 -u root -p --force dbname ，避免因编码不一致触发语法解析失败
