Navicat命令行不支持直接传参给SQL脚本变量，需用PowerShell/sed/Python等预处理替换${run_date}占位符后再执行；或在SQL文件头部用SET @run_date赋值，但须与业务语句同文件同会话。
Navicat 命令行不支持直接传参给 SQL 脚本中的变量
Navicat 的 navicat.exe（Windows）或 navicat（macOS/Linux）命令行工具本身没有内建的「参数绑定」机制，不能像 mysql -e "SET @date='2024-01-01'; SOURCE script.sql;" 那样动态注入变量。你写的 SQL 脚本里如果用了 @date 或 ${date} 这类占位符，Navicat 不会自动替换——它只会原样执行。
真正可行的方案：用外部脚本预处理 SQL 文件
核心思路是绕过 Navicat 的限制，在调用 Navicat 之前，先用 Shell / PowerShell / Python 把日期变量写进 SQL 文件里。Navicat 最终执行的是已填充好值的静态脚本。
- Windows 下推荐用
PowerShell+(Get-Content).Replace()，例如：Set-Variable dateStr "2024-06-15" (Get-Content "report.sql") -replace '\$\{run_date\}', $dateStr | Set-Content "report_filled.sql" & "C:\Program Files\PremiumSoft\Navicat Premium 16\navicat.exe" --run-sql "report_filled.sql" --connection "MyDB" - macOS/Linux 下用
sed -i '' "s/\${run_date}/$DATE/g" report.sql（注意 BSD sed 需空字符串参数） - 避免用
//或/* */包裹占位符，否则可能被误判为注释；建议统一用${run_date}这种不易冲突的格式 - 若 SQL 脚本含多条语句，确保预处理后仍保持语法正确（比如末尾不缺分号）
替代方案：改用 Navicat 内置的「运行 SQL 文件」+ 手动变量定义
如果你能接受每次运行前手动指定一次日期，可以在 SQL 文件头部显式赋值，再由 Navicat 执行：
SET @run_date = '2024-06-15'; SELECT * FROM sales WHERE sale_date = @run_date;
这个方式无需外部脚本，但失去了「动态传参」的自动化意义；且注意：SET 只在当前会话有效，必须和后续语句在同一个 SQL 文件中、且顺序不能颠倒。
- Navicat 的
--run-sql会开启新连接，所以SET @var必须和业务语句在同个文件、同次执行中 - MySQL 8.0+ 支持
SET STATEMENT控制临时行为，但不适用于普通变量传递 - PostgreSQL 用户别试
SET—— Navicat 对 PG 的变量支持更弱，\set是 psql 特有，Navicat 不识别
为什么不用 Navicat 自带的「计划任务」+ 参数化？
Navicat 的「计划任务」功能看似支持参数，但它只允许你为「导出/导入/备份」类操作配置路径、格式等固定字段，**不开放 SQL 脚本内容级变量替换接口**。你无法在任务设置里填一个「日期参数名」然后让 Navicat 去替换 SQL 里的占位符。
- 试图在计划任务里写
WHERE sale_date = ${date}→ 执行时会报错或查不到数据，因为 ${date} 未被解析 - 该功能底层调用的是 Navicat 封装的二进制逻辑，不暴露 SQL 文本重写能力
- 如果你依赖调度，建议把「预处理 + Navicat 执行」打包成一个定时脚本，而不是强求 Navicat 自己做变量注入
实际落地时最容易忽略的一点：SQL 文件编码。Windows 记事本保存的 UTF-8 带 BOM 的文件，Navicat 可能读取失败或乱码，导致变量替换后的语句执行报错。务必用 VS Code 或 Notepad++ 保存为「UTF-8 无 BOM」格式。
