Navicat定时任务“运行成功”但数据没变，先检查SQL脚本路径是否为相对路径——必须使用绝对路径且手动删除file://前缀；其次确认脚本中含DELETE/INSERT时已显式提交（Navicat默认不自动提交事务）。
Navicat定时任务“运行成功”但数据没变，先看SQL脚本路径是不是相对路径
navicat批处理作业或计划任务里用execute sql file步骤时，如果填的是./clean_logs.sql或sql/clean.sql这类相对路径，它不会报错，也不会提示，而是直接跳过执行——你看到的“成功”，其实是“没找到文件，但也不报错”的静默忽略。
必须用绝对路径，且不能带file://前缀（Navicat会自己加）：
- 右键SQL文件 → 「属性」→ 复制「位置」栏完整路径，例如
C:\Projects\db-maint\delete_old_logs.sql - 粘贴进作业步骤的「文件路径」框，手动删掉开头可能出现的
file:// - 路径含空格或中文？没问题，Navicat内部会处理；但别手动加双引号——它自己会包
SQL脚本本身执行了，但DELETE/INSERT没生效，检查是否漏了COMMIT
Navicat默认把SQL文件当「查询」执行，不是「命令行模式」。这意味着：即使脚本里写了DELETE FROM logs WHERE created_at ，只要没显式COMMIT;，且当前连接处于手动提交模式，那条DELETE就始终挂在那里，只对本次会话可见，关掉窗口就回滚。
解决方法很简单：
- 在SQL脚本末尾加上
COMMIT;（注意分号） - 或者在Navicat中打开「工具」→「选项」→「查询」→ 勾选「自动提交」（推荐批量维护场景）
- 避免在脚本里混用事务控制语句：比如开头
START TRANSACTION;但结尾没COMMIT;，这种组合在定时任务里极难排查
脚本里用了USE database_name;却没切换库，是因为连接参数没对齐
Navicat计划任务调用的是独立进程，它不会继承你当前GUI界面里的「活动数据库」上下文。如果你SQL脚本第一行是USE my_app;，但作业步骤里没指定目标库，Navicat就会在连接默认库（通常是information_schema或空库）里执行这条USE，然后后续所有表操作都找不到对象。
必须显式配置：
- 在批处理作业的
Execute SQL File步骤中，勾选「Connect to specified database」 - 在右侧输入框填准确的数据库名（大小写敏感，尤其PostgreSQL）
- 确保该数据库名和
USE语句里的完全一致；不一致时，Navicat不会报错，只是默默切不到
日志显示“已执行”但表数据纹丝不动，可能是SQL里字段/表名被双引号包围
Navicat导出的SQL文件默认给所有标识符加双引号（如"users"、"created_at"），这在PostgreSQL里合法，在MySQL里却可能触发严格模式报错——而Navicat定时任务遇到语法错误时，常静默失败，只记一条“完成”日志，不写具体错误。
快速验证方式：
- 打开SQL文件，搜索
"，确认是否有大量双引号包裹的表名或字段名 - 临时改一个最简单的语句测试：
SELECT COUNT(*) FROM "logs";→ 改成SELECT COUNT(*) FROM logs;再跑 - 若MySQL版本低于8.0，还可能因排序规则不兼容（如
utf8mb4_0900_ai_ci）导致建表失败，连带后续INSERT全跳过
Navicat定时任务的“成功”二字最容易骗人——它只代表进程启动并读完了脚本，不代表SQL真执行了、更不代表数据变了。真正关键的三个点：路径必须绝对、事务必须收口、上下文必须对齐。其他所有问题，基本都是这三个环节松动后衍生出来的。
