Navicat批处理作业不执行SQL脚本主因是Execute SQL File步骤路径错误或编码不匹配；须用绝对路径、UTF-8无BOM编码，并正确配置数据库连接与事务控制。
Navicat 批处理作业不执行 SQL 脚本？检查 Execute SQL File 步骤的路径和编码
navicat 的批处理作业里，execute sql file 步骤最常失败——不是语法错，而是文件根本没读进去。它只认绝对路径，且对中文路径、空格、特殊字符零容忍。相对路径（比如 ./init.sql）直接忽略，不报错也不提示。
实操建议：
- 右键 SQL 文件 → 「属性」复制完整路径，粘贴进作业步骤时手动删掉开头的
file://（Navicat 会自己加） - 确保文件保存为 UTF-8 无 BOM 编码；用记事本另存为时选「UTF-8」而非「UTF-8 with BOM」，否则可能报
SQL Error: 1064 - 如果脚本含
USE database_name;，必须勾选该步骤的Connect to specified database并填对库名，否则语句在连接默认库上下文中执行，USE会被跳过
多个 SQL 步骤串行执行但中途中断？重点看 Continue on error 和事务边界
默认情况下，任一步骤报错，整个批处理就停住。但 DBA 常需要「尽力执行」：比如建表失败不影响后续插入测试数据。这时不能只开 Continue on error，还得厘清事务范围。
关键点：
-
Execute SQL File和Execute SQL Statement默认各自开启独立事务，彼此不感知；想跨步骤回滚，得把所有语句合并到单个Execute SQL Statement步骤里，并用BEGIN; ... COMMIT;或ROLLBACK;显式控制 -
Continue on error开启后，错误步骤返回码是 1，后续步骤仍运行——但不会自动跳过依赖项（例如前一步没建表，后一步 INSERT 就真会报错） - 若需条件跳过，只能靠外部脚本预检 + Navicat 调用系统命令（如
cmd /c if exist ...），Navicat 内置逻辑不支持 if/else
定时触发批处理作业失败？Windows 服务模式 下的权限和环境变量陷阱
在 Windows 上设成「作为 Windows 服务运行」后，作业常卡在连接数据库或读文件，错误日志里只显示 Connection refused 或空路径。根本原因是服务账户没桌面交互权限，也拿不到当前用户的环境变量（比如 PATH 中的 MySQL 客户端路径）。
绕过方法：
- 改用「以当前用户身份运行」并勾选「登录时启动」，避免服务上下文隔离问题
- 所有数据库连接必须用完整参数：显式写明
host（别用localhost，它可能走 socket 而非 TCP）、port、username、password；密码不能存为变量引用，得填死 - 调用外部工具（如
mysqldump）时，路径必须绝对，且确认服务账户对该路径有读取+执行权限（常被忽略的是C:\Program Files\下的程序需要管理员提权）
为什么改了 SQL 文件内容，批处理还是跑旧逻辑？缓存和版本管理盲区
Navicat 不会监听文件变更，作业步骤一旦创建，就固化了当时读到的文件内容或 SQL 文本。你改了磁盘上的 .sql 文件，但作业里引用的仍是首次加载时的快照——除非重新编辑该步骤并点击「Load from file」。
防踩建议：
- 禁用「Load from file」后手动粘贴 SQL 的习惯；真要手写，务必每次修改后点「Save」再点「OK」，否则编辑框改了，步骤实际没更新
- 多人协作时，别共用一个本地 SQL 文件路径；应把脚本纳入 Git，作业中用 CI 生成带时间戳的绝对路径（如
D:\scripts\deploy_20240520.sql），避免覆盖冲突 - 调试阶段，在每步末尾加
SELECT 'step_x_done' AS status;，用 Navicat 日志窗口确认执行流，别只看最终结果
批处理真正的复杂点不在步骤拼接，而在于每个步骤背后隐含的上下文假设——连接状态、文件生命周期、账户权限边界。这些不会报错，只会让结果和预期差一条语句的距离。
