navicat导出向导不支持where条件，需先创建并保存带动态日期函数的select查询（如mysql用date_sub(now(), interval 1 day)，postgresql用current_date - interval '1 day'），再在导出向导中选择该已保存查询作为数据源。
navicat 导出向导不支持 where 条件，必须用查询结果导出
navicat 16 的标准导出向导（右键表 → 导出向导）只接受表名、视图名或已保存的查询，**不解析任何 where 子句**。你在“表名”栏输入 orders where order_date >= '2024-01-01' 会直接报错：unknown table 'orders where order_date >= '2024-01-01''。
真正可行的路径是：先写一个带日期函数的 SELECT 查询，执行并保存，再在导出向导中选择这个“查询”作为数据源。
- 新建查询 → 写类似
SELECT * FROM orders WHERE order_date >= DATE_SUB(NOW(), INTERVAL 1 DAY)（MySQL）或WHERE order_date >= CURRENT_DATE - INTERVAL '1 day'（PostgreSQL） - 务必点击 ▶ 执行，确认结果集是你想要的范围（注意右下角是否启用了“只读取前 N 行”，如需全量请设为 0）
- 点击保存（? 图标），命名为
export_orders_last_day—— 未保存的查询不会出现在后续导出列表中
动态日期函数必须写在查询里，不能靠导出向导变量自动替换
Navicat 的导出向导界面里确实有“文件名含日期”选项，但那个只是生成带时间戳的文件名（如 orders_20260728.csv），**完全不影响 SQL 查询逻辑本身**。很多人误以为勾选了就自动过滤当天数据，结果导出的仍是全表。
真正的动态过滤只能靠 SQL 函数实现，且不同数据库语法不同：
- MySQL：
DATE(order_date) = CURDATE()或更稳妥的order_date >= CURDATE() AND order_date - PostgreSQL：
order_date::DATE = CURRENT_DATE或order_date >= CURRENT_DATE AND order_date - SQL Server：
CAST(order_date AS DATE) = GETDATE()（注意GETDATE()含时间，需转日期）
别用 = '2026-07-28' 这类硬编码——它不会随每天自动更新，导出任务一建好就固定死了。
导出时选“查询”而非“表”，且字段类型要匹配
启动导出向导后，在第一步选择数据源时，**必须切换到左侧“查询”节点**，找到你刚保存的 export_orders_last_day，而不是在“表”节点里找 orders。这是最容易漏掉的关键步骤。
日期字段类型不一致是导出为空的最常见原因：
- 如果
order_date是DATETIME或TIMESTAMP，用= '2026-07-28'只会命中'2026-07-28 00:00:00'这一行 - 稳妥做法永远用范围条件：
order_date >= '2026-07-28' AND order_date - 右键表 → “设计表”，确认字段真实类型是
DATE、DATETIME还是TIMESTAMP，再决定函数写法
定时执行时，函数求值发生在 Navicat 连接时刻，不是调度时刻
如果你用 Windows 任务计划程序调用 --batch-job 执行导出任务，要注意：NOW()、CURDATE() 这些函数是在 Navicat 建立数据库连接并执行查询那一刻求值的，不是在任务被调度的那一刻。
这意味着只要任务按时触发、Navicat 能连上库，日期就是实时的。但有两个隐藏风险：
- 如果导出任务里用了
SYSDATE()（MySQL）且服务器时区与本地不一致，结果可能偏移一天 - 若任务跨午夜运行（比如 23:59 开始，执行到 00:01），
CURDATE()仍返回启动时的日期，不会中途刷新 - 避免在大表上用
DATE(order_date) = ...—— 它无法走索引，可能超时或卡死（Navicat 默认查询超时 300 秒）
最终效果取决于 SQL 本身是否真正在每次执行时动态计算，而不是 Navicat 或调度器有多“智能”。函数写对了，它每天自然不同；写错了，十年如一日导出同一堆数据。
