执行报错时如何利用批量执行多个SQL文件排查

用 mysql --defaults-file=./my.cnf --force --verbose 批量执行可精准定位报错文件及行号，配合 grep -n 等命令快速筛选真实语句行，避免 source 命令因不解析SQL而缺失上下文。

SQL 文件批量执行时报错，怎么快速定位是哪个文件、哪一行出问题

批量执行多个 .sql 文件时，只要其中一个语句语法错误（比如少个分号、引号不闭合、关键字拼错），整个流程就可能中断，但默认输出往往只显示「error 1064」或「near line x」，而这个 x 是当前文件内的行号，不是绝对路径+行号——你根本不知道错在哪个文件里。

关键不是重试，而是让错误带上下文。推荐用 mysql 客户端加 --verbose 和 --force 组合：

--force：遇到错误不停止，继续执行后续文件（否则第一个错就退出）
--verbose：打印每条 SQL 执行前的完整语句，出错时会明确标出「Failed to execute: ...」并附上当前文件名和行号
配合 --defaults-file 避免密码明文出现在命令行（安全且避免被 history 记录）

示例命令：mysql --defaults-file=./my.cnf --force --verbose ，前提是把所有 SQL 文件用 cat *.sql > all.sql 合并，并确保每个文件末尾有空行（防止语句粘连）。

MySQL 5.7 vs 8.0 批量执行时常见的语法兼容性坑

同一份 SQL 在不同版本报错，大概率不是你写错了，而是服务端 SQL 模式或保留字变了。最典型的是 GROUP BY 严格模式和窗口函数支持。

MySQL 5.7 默认开启 ONLY_FULL_GROUP_BY，但某些旧导出脚本用 SELECT id, name FROM t GROUP BY id（没包含非聚合字段 name），会直接报错；8.0 默认仍开启，但部分云数据库可能关了
含 ROW_NUMBER() 或 OVER() 的语句，在 5.7 下必然报错「FUNCTION ROW_NUMBER does not exist」，这不是语法错，是版本不支持
JSON_EXTRACT 在 5.7 中要求路径参数必须是字符串字面量（如 '$.id'），不能是变量或拼接结果，否则报错「Invalid JSON path expression」

查当前模式：SELECT @@sql_mode;；临时关闭严格模式（仅调试用）：SET sql_mode = '';，但别写进批量脚本里。

用 sed / awk 快速筛出疑似语法错误的 SQL 行（跳过注释和空行）

当错误提示说「near line 123」，但文件有大量注释和空行，手动数容易错。别打开编辑器硬找，用命令行快速过滤真实语句行：

提取所有非空、非注释的物理行（含多行语句）：grep -vE '^[[:space:]]*(#|--|$)' file.sql | grep -v '^[[:space:]]*$'
如果想看第 123 行附近上下文（含原始行号）：grep -n -E '^[^[:space:]#;]|;$' file.sql | sed -n '121,125p' —— 这能排除纯注释行，只显示可能含语句或分号的行
注意：MySQL 不强制每行一条语句，所以 ; 可能在行中或行尾；真正起作用的是分号本身，不是换行

常见误判点：INSERT INTO t VALUES (1, 'a'); -- comment 是合法单行；但 INSERT INTO t VALUES (1, 'a（引号没闭合）会跨行，grep 看不到完整结构，这时得用 mysql --verbose 实际执行来暴露。

为什么 source 命令在 MySQL CLI 里不显示详细错误位置

source 是 MySQL 客户端内置命令，它把文件内容喂给服务器，但错误返回时只带 server 报的原始信息，不反推文件路径和偏移。也就是说，ERROR 1064 (42000): You have an error in your SQL syntax... 后面不会补「in file init.sql at line 42」。