MySQL中DATE()分组会导致索引失效，建议建生成列并索引；注意时区转换；Oracle用TRUNC()而非TO_CHAR；PostgreSQL用::DATE或表达式索引；需排除NULL并确认业务日期边界。
MySQL里用DATE()提取日期再分组统计，但要注意时区和索引失效
直接对order_time字段用DATE(order_time)做分组，能拿到按天聚合的订单量，但会跳过索引——哪怕order_time上有B-tree索引。因为函数作用于列后，优化器无法下推索引范围扫描。
实操建议：
- 如果数据量不大（比如百万级以下），
SELECT DATE(order_time) AS day, COUNT(*) FROM orders GROUP BY DATE(order_time)够用，写法直白 - 想走索引？改用范围查询+循环补全缺失日期，或建生成列：
ALTER TABLE orders ADD COLUMN order_date DATE GENERATED ALWAYS AS (DATE(order_time)) STORED，再给order_date加索引 - 注意时区：MySQL默认用系统时区解析
order_time，如果存的是UTC时间，得先CONVERT_TZ(order_time, '+00:00', '+08:00')再DATE()，否则凌晨下单可能被算进前一天
Oracle必须用TRUNC()，且不能只写TRUNC(order_time)
TRUNC(order_time)在Oracle里确实等价于“归零到当天0点”，但它默认按当前会话NLS_DATE_FORMAT截断，而分组时若order_time含时分秒，TRUNC()结果仍是DATE类型（含时分秒=0），不影响分组逻辑——这点常被误以为要转成字符串。
常见错误现象：
- 写了
TO_CHAR(TRUNC(order_time), 'YYYY-MM-DD')再分组：多此一举，还让索引彻底失效 - 漏写
GROUP BY里的TRUNC(order_time)，只写SELECT TRUNC(order_time)：报ORA-00979错误 - 用
TRUNC(order_time, 'DD')：语法合法但冗余，'DD'是默认模式，不写更安全
正确写法：SELECT TRUNC(order_time) AS day, COUNT(*) FROM orders GROUP BY TRUNC(order_time)
PostgreSQL没有TRUNC()，得用DATE()或CAST()，但要注意字段类型
PostgreSQL的DATE(order_time)只对TIMESTAMP WITH TIME ZONE或WITHOUT TIME ZONE有效；如果order_time是TEXT或JSONB里存的字符串，得先TO_TIMESTAMP()转换，否则报错function date(text) does not exist。
性能提示：
- 用
order_time::DATE比DATE(order_time)稍快，底层走类型强制转换，避免函数调用开销 - 如果经常按天查，建表达式索引：
CREATE INDEX idx_orders_order_date ON orders ((order_time::DATE)) - 跨时区场景下，
order_time AT TIME ZONE 'Asia/Shanghai'必须放在::DATE前，顺序反了会按服务器本地时区截断
所有数据库都绕不开的空值和边界问题
NULL值在GROUP BY中自成一组，导致统计结果多出一行NULL，实际业务中往往要排除。另外，严格意义的“按天统计”需确认是否包含今天——有些BI工具默认截止到昨日，而SQL跑批可能要求WHERE order_time >= CURRENT_DATE - INTERVAL '7 days'这种动态条件。
关键细节：
- 加
WHERE order_time IS NOT NULL再分组，比在HAVING里过滤更早剪枝 - 用
CURRENT_DATE而非NOW()作时间基准：前者只取日期部分，后者带时分秒，容易因执行时刻卡在临界点（如23:59:59）漏掉当天数据 - 如果订单表有软删除字段（如
is_deleted = 0），务必在WHERE里加上，否则回收站里的历史订单也会被计入
日期函数本身不难，难的是它一动，索引、时区、空值、业务口径全跟着动——动手前先看执行计划，别信“看起来对”。
