Navicat批量执行SQL文件卡住的根本原因是默认将每个.sql文件作为独立事务，遇错即停且不自动跳转下一文件；需勾选“忽略SQL语句错误”、用“运行SQL文件”功能、修正字符集声明、清理特殊注释、避免中文路径，并通过NOW(3)和@start变量手动计时。
Navicat 批量执行 SQL 文件时卡在第一个文件不继续
根本原因不是 navicat 坏了，而是它默认把每个 .sql 文件当做一个独立事务执行，且遇到任意一条语句报错（比如 create table if not exists 在表已存在时触发警告、或 insert 主键冲突），就会中断整个文件的执行——更关键的是，它不会自动跳到下一个文件，而是停住。
实操建议：
- 打开「工具」→「选项」→「SQL 编辑器」，勾选
忽略 SQL 语句错误并继续执行（注意：这个选项只对单个文件内的多条语句有效，不影响跨文件） - 真正批量跑多个文件，必须用「运行 SQL 文件」功能（右键连接 →
运行 SQL 文件），不能靠双击逐个打开 - 确保所有 SQL 文件末尾没有未闭合的注释（
/*没配*/）或孤立的反引号，这类语法问题会让 Navicat 解析失败并静默终止
MySQL 8.0+ 下批量执行含 SET NAMES utf8mb4 的 SQL 文件失败
Navicat 在连接 MySQL 8.0+ 时默认使用 utf8mb4_0900_as_cs 排序规则，而很多老 SQL 文件开头写的 SET NAMES utf8mb4 本身没问题，但若文件里混用了 utf8（3 字节）字面量或旧版导出的注释，MySQL 服务端会直接拒绝执行整条语句，Navicat 就卡住不动。
实操建议：
- 统一把文件头的
SET NAMES utf8mb4改成SET NAMES utf8mb4 COLLATE utf8mb4_0900_as_cs（匹配当前连接排序规则） - 用文本编辑器批量删掉所有
/*!40101 SET ... */这类 MySQL 特有注释——Navicat 对它们的兼容性差，尤其在批量模式下容易误判为语法错误 - 如果文件来自 mysqldump，导出时加参数
--skip-set-charset --default-character-set=utf8mb4，避免嵌入不可控的字符集指令
如何让 Navicat 批量执行时显示每条语句的实际耗时
Navicat 的「运行 SQL 文件」界面默认只显示“成功”或“失败”，不输出执行时间，但真实场景中你得知道哪个文件拖慢了整体流程。它底层调用的是 MySQL 客户端协议，不走标准日志通道，所以常规日志开关无效。
实操建议：
- 在每个 SQL 文件最开头插入：
SELECT CONCAT('START: ', NOW(3)) AS '---';，结尾加：SELECT CONCAT('END: ', NOW(3), ' | ELAPSED: ', TIMEDIFF(NOW(3), @start)) AS '---'; - 在第一个文件第一行手动设变量：
SET @start = NOW(3);，后续文件不用再设（Navicat 批量执行时复用同一个 session） - 注意：不能用
PREPARE/EXECUTE包裹这些 SELECT，Navicat 对预处理语句的批量解析极不稳定，大概率报Unknown prepared statement handler
Windows 下路径含中文或空格导致 Navicat 找不到 SQL 文件
这不是 Navicat 的 bug，是它调用 MySQL 客户端时没对路径做 shell 转义。比如路径是 C:\我的项目\init\01_users.sql，Navicat 会传给 mysql.exe 原样字符串，而 mysql.exe 在 Windows 下只认英文路径和短横线，遇到中文直接返回 ERROR 2002 (HY000): Can't connect to local MySQL server（其实是文件打开失败，但它伪装成连接错误）。
实操建议：
- 把所有 SQL 文件移到纯英文无空格路径下，例如
C:\navi_sql\，然后用「运行 SQL 文件」对话框里的「添加文件」按钮一个个选，别用「添加文件夹」 - 如果必须用中文路径，先用
mklink /D创建符号链接映射到英文路径，Navicat 能正常识别链接目标 - 检查 Navicat 日志（菜单「帮助」→「日志文件」）里是否有
Failed to open file类提示，这是最直接的证据
SET SQL_MODE='STRICT_TRANS_TABLES'，它会影响后面所有文件，但 Navicat 界面完全不提示。一旦某个文件依赖宽松模式，就悄无声息地写入脏数据。 
