用CURRENT_DATE筛选当天数据查不到结果，主因是DATETIME/TIMESTAMP字段与DATE类型直接等值比较失败；正确做法是用范围查询：order_time>=CURRENT_DATE AND order_time
用 CURRENT_DATE 筛选当天数据时，为什么查不到结果？
多数情况不是函数写错了，而是字段类型不匹配。比如 order_time 是 DATETIME 或 TIMESTAMP 类型（带时分秒），而 CURRENT_DATE 只返回日期部分（如 '2024-05-20'），直接等值比较会失败。
常见错误写法：
SELECT * FROM orders WHERE order_time = CURRENT_DATE;
- ✅ 正确思路：把带时间的字段“截断”成日期，或用范围比较
- ✅ 推荐方式是用范围：从今天 00:00:00 到明天 00:00:00 前
- ⚠️ 注意：MySQL 中
CURRENT_DATE返回DATE类型；PostgreSQL 和 SQL Server 也支持，但 SQL Server 更常用CAST(GETDATE() AS DATE)
CURRENT_DATE 在不同数据库中的等效写法
不是所有系统都叫这个名字，尤其在老版本或特定方言里：
- MySQL / PostgreSQL / SQLite：直接用
CURRENT_DATE（或CURRENT_DATE()函数形式，效果相同） - SQL Server：不支持
CURRENT_DATE，改用CAST(GETDATE() AS DATE)或CONVERT(DATE, GETDATE()) - Oracle：用
TRUNC(SYSDATE)，因为SYSDATE带时间，TRUNC会归零时分秒 - ⚠️ 避免写
NOW()::DATE（PostgreSQL）或DATE(NOW())（MySQL）——虽然能用，但可读性差，且DATE()是 MySQL 特有函数，跨库迁移易出错
筛选“今天的数据”最稳妥的 WHERE 写法
绕开类型隐式转换，明确控制边界，兼容性和性能都更好：
SELECT * FROM orders WHERE order_time >= CURRENT_DATE AND order_time < CURRENT_DATE + INTERVAL '1' DAY;
- ✅
CURRENT_DATE + INTERVAL '1' DAY在 PostgreSQL/MySQL 8.0+ / SQLite 支持；MySQL 5.7 用DATE_ADD(CURRENT_DATE, INTERVAL 1 DAY) - ✅ 这种写法能走
order_time字段上的索引（如果是 B-tree 索引） - ❌ 不要用
DATE(order_time) = CURRENT_DATE：对字段加函数会阻止索引使用，大数据量时明显变慢 - ⚠️ 如果字段是
TIMESTAMP WITH TIME ZONE（如 PostgreSQL），还要确认时区是否一致——CURRENT_DATE按服务器时区算，可能和业务时区不符
为什么不用 NOW() 或 SYSDATE 直接比？
它们返回完整时间戳，精度到秒甚至微秒，用于“精确到秒”的场景没问题，但做“当天”筛选反而容易出错：
- ❌
WHERE order_time = NOW()::DATE：看似取了日期，但强制类型转换可能触发隐式 cast，某些驱动或 ORM 会报错 - ❌
WHERE order_time >= NOW() - INTERVAL '24 hours'：逻辑上是过去24小时，不是“今天”，跨零点时会漏掉或重复 - ✅ 真正要“今天”，必须以日历日为单位，而非相对时间窗口
- ⚠️ 尤其在定时任务中（比如每天凌晨跑昨日报表），用
CURRENT_DATE - INTERVAL '1' DAY才是昨天，别用NOW() - INTERVAL '1 day'—— 后者在下午3点执行时，得到的是“1天前”，不是“昨天”
时区、字段类型、索引可用性——这三个点没对齐，CURRENT_DATE 就会从便利工具变成排查半天的陷阱。
