Navicat 17计划任务不支持SQL用户变量（如@var），仅支持内置宏${DATE}等（限备份/导出任务）和操作系统环境变量（需显式传入并由数据库原生读取）。
Navicat 17计划任务里SQL变量为什么全都不起作用
navicat 17的「计划任务」根本不支持用户变量（@var）或会话变量（set @x := ...），它调用的是命令行模式下的 sql 执行器，而非交互式客户端会话。所有带 @ 前缀的变量赋值、引用，在计划任务中会被直接忽略或报语法错误——这不是配置问题，是设计限制。
哪些“变量”在Navicat计划任务中实际可用
真正能用的只有两类：
- Navicat 内置的运行时宏：
${DATE}、${TIME}、${DATETIME}，仅在「备份」「导出」等图形化任务类型中生效，SQL 脚本里无效 - 操作系统级环境变量：需在 Windows 任务计划程序的「操作 → 添加参数」中显式传入，例如：
--env "LOG_DAYS=30"，然后在 SQL 脚本里靠数据库原生方式读取（如 MySQL 的sys_eval()或 PostgreSQL 的current_setting('app.log_days')，但需提前配置）
想动态生成条件？别写SET @days = 30，改用拼接或函数
常见错误是把手动执行时能跑的脚本直接丢进计划任务，比如：
SET
- 硬编码常量（最稳）：
DELETE FROM logs WHERE created_at - 用数据库函数替代变量：
DELETE FROM logs WHERE created_at （PostgreSQL） - 拆成多条独立语句并确保每条都带完整逻辑，避免跨行依赖
脚本里用了变量却没报错？那是执行器根本没解析它
Navicat 计划任务默认以「查询模式」执行 SQL 文件，对语法容错高：遇到不认识的 SET @x 不报错，而是跳过；WHERE col = @x 中的 @x 被当作未定义标识符，最终变成 WHERE col = NULL —— 你看到“执行成功”，其实一行都没删。
最容易被忽略的一点：Navicat 不会在日志里提示“变量被忽略”，只记录“SQL executed successfully”。真要验证，得去数据库查实际影响行数，或者加 SELECT ROW_COUNT(); 在脚本末尾输出结果。
