current_date返回数据库服务器本地时间而非用户时区时间，易致报表日期偏差；需查时区配置并用范围查询替代等值匹配以避免索引失效和数据遗漏。
CURRENT_DATE 返回的是数据库服务器本地时间，不是你电脑的系统时间
很多报表需求默认以为 CURRENT_DATE 会按自己所在时区取当天日期，结果导出数据总差一天。它实际返回的是数据库实例所在服务器的操作系统当前日期——比如你的 MySQL 实例部署在新加坡 AWS 服务器上，即使你在北京时间下午三点跑查询，CURRENT_DATE 仍返回新加坡时间（UTC+8）的“今天”，和你本地可能一致，但一旦服务器跨时区（比如 UTC），就必然出错。
实操建议：
- 先执行
SELECT CURRENT_DATE, NOW();确认服务器时区和当前时间戳 - 查数据库时区配置：
SELECT @@time_zone;（MySQL）、SHOW TIMEZONE;（PostgreSQL） - 如果业务要求按用户所在时区生成报表，不要硬靠
CURRENT_DATE，改用带时区转换的表达式，例如 PostgreSQL 中：CURRENT_DATE AT TIME ZONE 'Asia/Shanghai'
在 WHERE 条件中直接用 CURRENT_DATE 可能导致索引失效
写 WHERE order_date = CURRENT_DATE 看似简洁，但如果 order_date 是 DATETIME 或 TIMESTAMP 类型，而 CURRENT_DATE 是纯日期（无时间部分），数据库会隐式把 CURRENT_DATE 转成 '2024-06-15 00:00:00'，然后做等值匹配——这几乎不可能命中当天所有记录（除非所有订单都恰好发生在 00:00:00）。
正确做法是范围查询：
- MySQL/PostgreSQL：用
WHERE order_date >= CURRENT_DATE AND order_date - SQL Server：用
WHERE order_date >= CAST(CURRENT_DATE AS DATETIME) AND order_date - 确保
order_date字段上有索引，且类型与查询逻辑匹配（如用DATE类型存日期可简化判断）
不同数据库对 CURRENT_DATE 的支持程度和行为略有差异
CURRENT_DATE 是 SQL 标准函数，主流数据库都支持，但细节要注意：
- MySQL 和 PostgreSQL 中，
CURRENT_DATE是函数，可不加括号（CURRENT_DATE等价于CURRENT_DATE()）；SQLite 必须写成CURRENT_DATE（不支持括号） - SQL Server 不支持
CURRENT_DATE，要用CAST(GETDATE() AS DATE)或CONVERT(DATE, GETDATE()) - Oracle 中推荐用
TRUNC(SYSDATE)，因为CURRENT_DATE会受会话时区影响，而SYSDATE是数据库服务器时间 - ClickHouse 没有
CURRENT_DATE，得用TODAY()
生成日报时，别只依赖 CURRENT_DATE 做分区或文件名
报表调度任务（比如 Airflow 或 crontab）常在凌晨 1 点跑昨天的数据，这时用 CURRENT_DATE 会拿错日期——它返回的是“运行时刻”的日期，不是“报表覆盖的日期”。
稳妥做法：
- 调度任务显式传入日期参数（如
ds='2024-06-14'），SQL 中用绑定变量或模板替换，例如：WHERE dt = '{{ ds }}' - 若必须用函数推算，根据调度时间反推：凌晨 1 点跑昨日数据，可用
CURRENT_DATE - INTERVAL '1 day' - 避免在建表分区、导出文件名里硬编码
CURRENT_DATE，否则重跑历史报表时会写到错误分区
时区、索引、数据库方言、调度上下文——这四个点没对齐，CURRENT_DATE 就容易从便利变成隐患。
