Oracle中GROUP BY DATE(log_time)少一小时，是因TIMESTAMP WITH TIME ZONE隐式转本地时区再截断所致；应统一转UTC后TRUNC(log_time AT TIME ZONE 'UTC', 'DD')。
GROUP BY本身不截断，所谓“截断写入”是误用或配置不当导致的隐式行为——本质是时区转换、字段精度丢失或NLS设置干扰了分组键的生成。
GROUP BY DATE(log_time) 在 Oracle 中为什么总少一小时？
Oracle 的 DATE 类型不存时区，但会受会话级 NLS_DATE_FORMAT 和 SESSIONTIMEZONE 影响。如果日志用 TIMESTAMP WITH TIME ZONE 写入（比如 '2026-11-03 00:15:22.123 +08:00'），而你直接 GROUP BY DATE(log_time)，Oracle 会先隐式转成本地会话时区再截断，凌晨数据就可能被砍进前一天。
- 查当前会话时区：
SELECT SESSIONTIMEZONE FROM DUAL; - 查数据库默认时区：
SELECT DBTIMEZONE FROM DUAL; - 安全做法：统一转 UTC 后截断：
GROUP BY TRUNC( log_time AT TIME ZONE 'UTC', 'DD' )
用 TRUNC(log_time, 'HH24') 分组却漏掉整点前的数据
Oracle 的 TRUNC(datetime, 'HH24') 是向下取整到最近的整点，比如 '2026-11-03 09:59:59' 会被截成 '2026-11-03 09:00:00'，没问题；但如果你用的是 TO_CHAR(log_time, 'YYYY-MM-DD HH24')，而 NLS_DATE_LANGUAGE 是中文或非英语环境，HH24 可能被忽略，实际变成 HH（12 小时制），导致 13 点变 1 点，分组错乱。
- 强制指定语言：
TO_CHAR(log_time, 'YYYY-MM-DD HH24', 'NLS_DATE_LANGUAGE=AMERICAN') - 更稳：用
TRUNC(log_time, 'HH24')，它不依赖 NLS，且返回DATE类型，可直接建索引 - 确认索引是否生效：
EXPLAIN PLAN FOR SELECT COUNT(*) FROM log_table GROUP BY TRUNC(log_time, 'HH24');，看执行计划里有没有INDEX RANGE SCAN
GROUP BY 截断后 COUNT(*) 比预期少——其实是 NULL 值被过滤了
Oracle 对 GROUP BY 字段中为 NULL 的行，会单独聚成一组（不是丢弃），但如果你用的是 TRUNC(log_time, 'DD')，而部分日志的 log_time 是 NULL，那这一组就会出现在结果里，且 COUNT(*) 只统计该组内行数。问题在于：你没意识到这组存在，又没在应用层处理，看起来就像“总数少了”。
- 快速验证：
SELECT COUNT(*), COUNT(log_time), COUNT(TRUNC(log_time, 'DD')) FROM log_table;—— 三个值不等，说明有空值 - 补救查询：
GROUP BY NVL(TRUNC(log_time, 'DD'), DATE '1970-01-01')把 NULL 显式归到一个兜底日期 - 长期建议：建检查约束或触发器，禁止
log_time IS NULL
最易被忽略的点：Oracle 的 TRUNC 函数在分区表上若用于分区键（如按天分区），必须确保截断表达式与分区定义完全一致，否则分区裁剪失效，哪怕加了索引也得全扫——别只盯着 GROUP BY，先看 WHERE 条件能不能命中分区。
