Navicat计划任务不支持用户变量@var，因其调用命令行执行器而非交互式会话，@var被静默忽略导致WHERE条件恒为假；仅${DATE}等模板变量在图形化任务中有效，环境变量需系统级传入，动态逻辑应改用数据库内置函数如DATE_SUB(NOW(), INTERVAL 30 DAY)。
Navicat计划任务根本不解析@var这类用户变量
不是配置错了，是压根不支持。navicat 17+ 的「计划任务」调用的是命令行 sql 执行器（类似 mysql -e），而非交互式会话，所有 set @x := ...、@x 引用都会被跳过或当作无效标识符处理。你看到“执行成功”，实际 where col = @x 等价于 where col = null，条件永远不成立。
哪些“变量”在计划任务里真能用
只有两类可依赖：
-
${DATE}、${TIME}、${DATETIME}：仅在「备份」「导出」等图形化任务类型中生效，写进 SQL 脚本里完全无效 - 操作系统环境变量：需在 Windows 任务计划程序或 cron 中显式传入，例如
--env "DAYS=7"；然后在 SQL 中靠数据库原生方式读取——MySQL 需配合sys_eval()（已废弃且需 SUPER 权限），PostgreSQL 可用current_setting('app.days')（需提前SET app.days = '7'）
SQL脚本里用了@var却没报错？那是被静默忽略了
Navicat 计划任务默认以宽松模式解析 SQL，遇到不认识的 SET @days = 30; 直接跳过，后续引用 @days 时当未定义处理，不报错也不警告。日志只写 SQL executed successfully，但实际影响行数为 0。验证方法只有两个：SELECT ROW_COUNT(); 加在脚本末尾，或执行后手动查表数据变化。
想动态删老数据？别碰@var，改用数据库函数硬写
把依赖变量的逻辑，直接换成数据库内置函数表达：
- MySQL：用
DATE_SUB(NOW(), INTERVAL 30 DAY)替代@days - PostgreSQL：用
NOW() - INTERVAL '30 days' - 如果天数要可配，就拆成多个固定脚本（如
cleanup_7d.sql、cleanup_30d.sql），计划任务分别调用
最易被忽略的一点：Navicat 不会在任何界面或日志里提示“变量被跳过”，你得自己加 SELECT 或查数据才能确认它到底干了什么。
