多次写 CURRENT_DATE 会导致结果不一致，因SQL标准要求每次出现都独立调用系统时钟，可能跨日；推荐用WITH子句固化或应用层传参确保一致性。
为什么多次写 CURRENT_DATE 会导致结果不一致
在一条 SQL 语句里反复出现 CURRENT_DATE（比如 SELECT、WHERE、ORDER BY 各用一次），数据库每次都会重新调用系统时钟——哪怕间隔微秒级，理论上也可能跨日（尤其在午夜执行时）。这不是 bug，是标准行为：SQL 标准规定标量函数每次出现都独立求值。
用 WITH 子句提前固化日期值
最直接可靠的解法是把 CURRENT_DATE 提前算好、存进一个命名的临时结果集，后续全部引用它。这样整个查询只调用一次系统时钟。
WITH today AS ( SELECT CURRENT_DATE AS dt ) SELECT u.name, u.created_at FROM users u CROSS JOIN today WHERE DATE(u.created_at) = today.dt AND u.status = 'active';
-
CROSS JOIN today把单行日期广播到所有记录，避免子查询重复执行 - 别名
dt可复用在 WHERE、SELECT、HAVING 等任意位置 - PostgreSQL、SQL Server、Oracle、Snowflake 都支持；MySQL 8.0+ 也支持
用变量或参数替代（适用特定场景）
如果是在应用层拼 SQL 或使用存储过程，更推荐把日期作为参数传入，彻底脱离数据库时钟依赖。
- 应用代码中先调一次
new Date()或datetime.date.today()，再作为绑定参数传给 SQL - 存储过程中声明变量：
DECLARE @today DATE = GETDATE();（SQL Server）或DECLARE today DATE DEFAULT CURRENT_DATE;（MySQL） - 优势：可测试性高、时区可控、避免任何时钟漂移风险
- 注意：不能用于视图或物化查询，因为参数需外部注入
CURRENT_DATE 在不同上下文的行为差异
CURRENT_DATE 看似简单，但实际表现受执行环境影响很大：
- 在同一个事务中多次调用，PostgreSQL 和 Oracle 会返回相同值（事务快照时间），但 MySQL 和 SQL Server 默认每次调用都实时取系统时间
- 在触发器里用
CURRENT_DATE，可能和主语句的“当前日期”不一致，尤其涉及延迟执行或并行 DML - 跨时区连接时，
CURRENT_DATE返回的是服务器时区的日期，不是客户端本地日期——别误以为它自动适配
真正需要“语句内一致”的地方，别赌数据库实现细节，老实用 WITH 或参数固化。
