CURRENT_DATE 返回 DATE 类型，格式为 YYYY-MM-DD；它取数据库服务端系统时间，不带时间部分，非传统函数而是标量表达式，使用时需注意字段类型匹配与数据库兼容性。
CURRENT_DATE 返回的是什么类型和格式
CURRENT_DATE 是标准 SQL 提供的日期字面量函数，返回数据库服务器当前日期（不带时间部分），类型通常是 DATE，格式为 YYYY-MM-DD。注意：它不依赖客户端时区，只取数据库服务端系统时间；不同数据库对时区处理略有差异，比如 PostgreSQL 默认按服务器时区，MySQL 则受 time_zone 系统变量影响。
常见错误现象：CURRENT_DATE 在某些 ORM 或可视化工具里显示为空或报错，往往是因为该环境不支持标准 SQL 函数（如旧版 SQLite 需用 date('now')）。
- PostgreSQL、SQL Server（2008+）、Oracle、Snowflake、DuckDB 均原生支持
CURRENT_DATE - MySQL 支持，但要注意：若会话
time_zone设为+00:00而服务器在东八区，可能比本地晚 8 小时 - SQLite 不支持
CURRENT_DATE作为函数调用（会报no such function: CURRENT_DATE），得改用date('now')
在 INSERT 和 WHERE 中怎么安全使用 CURRENT_DATE
直接写进语句即可，无需引号、也不用加括号（它不是传统函数，是标量表达式）。但要注意字段类型匹配和默认值场景。
示例：向订单表插入今日下单记录
INSERT INTO orders (order_id, customer_id, order_date) VALUES (1001, 42, CURRENT_DATE);
常见错误现象：如果 order_date 是 TIMESTAMP 类型，有些数据库（如 MySQL）会隐式转成 YYYY-MM-DD 00:00:00，导致当天下午查不到这条记录——应改用 CURRENT_TIMESTAMP 或显式 cast。
- WHERE 中用于范围筛选时，
WHERE order_date = CURRENT_DATE只能命中严格等于当天 00:00:00 的记录（极少）；更合理的是WHERE order_date >= CURRENT_DATE AND order_date （PostgreSQL/MySQL）或 <code>WHERE order_date = CAST(CURRENT_DATE AS DATE)（SQL Server） - 建表时不能把
CURRENT_DATE当作列默认值（除 PostgreSQL 外多数不支持），MySQL 需用CURRENT_DATE字面量配合DEFAULT，但仅限DATE类型字段
和 NOW()、SYSDATE()、GETDATE() 有什么关键区别
本质区别在于是否含时间部分和是否可被事务“冻结”：
-
CURRENT_DATE：只有日期，事务中多次调用返回相同值（标准 SQL 行为） -
NOW()（MySQL/PostgreSQL）或GETDATE()（SQL Server）：返回完整时间戳，且在事务内每次调用都可能不同（取决于实现） -
SYSDATE()（Oracle/MySQL）：返回操作系统当前时间，不受事务影响，精度更高，但跨库迁移风险大
性能影响很小，但语义混淆会导致 bug。比如用 NOW() 做分区键裁剪日期范围，结果因毫秒级差异漏掉数据；而 CURRENT_DATE 更适合做“今天统计”这类确定性逻辑。
跨数据库兼容写法怎么处理
没有 100% 兼容的写法，但可收敛到两种主流模式：
- 如果只要日期（无时间），优先用
CURRENT_DATE，并在部署前确认目标数据库版本支持（如 MySQL ≥ 4.1，PostgreSQL ≥ 7.3） - 若需兼容 SQLite，统一改用
date('now')，但注意它在 PostgreSQL/MySQL 中不是标准语法，需动态替换或抽象到 DAO 层 - 避免用字符串拼接日期（如
'2024-06-15'），否则失去自动更新能力；也别依赖TO_CHAR(NOW(), 'YYYY-MM-DD')这类转换，增加开销且类型不一致
最容易被忽略的一点：很多 ETL 工具或 BI 平台（如 Metabase、Tableau）会在查询前加一层时区转换，导致你看到的 CURRENT_DATE 和数据库实际值不一致——建议先在数据库命令行里执行 SELECT CURRENT_DATE, NOW(); 对齐基准。
