直接 group by hour(time_col) 会漏掉空小时，因该操作仅对实际存在记录分组；补全需先生成完整小时序列再 left join，且须用 date_trunc 截断、coalesce 处理 null、注意时区转换。
为什么直接 GROUP BY HOUR(time_col) 会漏掉空小时
因为 SQL 的 GROUP BY 只对实际存在的记录分组，如果某个小时内没有任何业务数据（比如凌晨 2–4 点没订单），那这个小时压根不会出现在结果里。你看到的“缺省时间点”，本质是数据源缺失，不是聚合逻辑错了。
补全的关键不是改 GROUP BY，而是先构造出完整的时间序列，再用 LEFT JOIN 把业务数据挂上去。
怎么生成连续的小时维度表（不依赖物理表）
多数现代数据库支持递归 CTE 或生成函数，避免手动建表。注意起止时间必须覆盖你查询的实际范围，否则补不全。
- MySQL 8.0+：用
WITH RECURSIVE从最小时间开始逐小时推到最大时间 - PostgreSQL：用
GENERATE_SERIES()最简洁，比如GENERATE_SERIES('2024-01-01 00:00'::TIMESTAMP, '2024-01-01 23:00', '1 hour') - SQL Server：用
master..spt_values或递归 CTE，但要注意性能，超 100 小时建议用数字辅助表
示例（PostgreSQL）：
WITH hours AS (
SELECT GENERATE_SERIES(
DATE_TRUNC('hour', MIN(event_time)),
DATE_TRUNC('hour', MAX(event_time)),
'1 hour'
) AS hour_start
FROM logs
)
SELECT h.hour_start, COALESCE(COUNT(l.id), 0) AS cnt
FROM hours h
LEFT JOIN logs l ON DATE_TRUNC('hour', l.event_time) = h.hour_start
GROUP BY h.hour_start
ORDER BY h.hour_start;
关联时为什么必须用 DATE_TRUNC('hour', …) 而不是 HOUR() + DATE()
HOUR() 只返回 0–23，丢弃日期信息；DATE() 又丢弃小时信息。两者拼起来看似能还原，但跨天场景会错乱（比如 '2024-01-01 23:00' 和 '2024-01-02 23:00' 的 HOUR()+DATE() 结果不同，但你可能想按自然小时对齐）。
- 正确做法：统一用
DATE_TRUNC('hour', time_col)（PG/Redshift）或DATEADD(hour, DATEDIFF(hour, 0, time_col), 0)（SQL Server）截断到小时精度 - MySQL 用户注意：
DATE_FORMAT(time_col, '%Y-%m-%d %H:00:00')比STR_TO_DATE(CONCAT(DATE(time_col), ' ', HOUR(time_col), ':00:00'), '%Y-%m-%d %H:%i:%s')更可靠，后者在时区或格式异常时易报错
补全后 COUNT(*) 为 0 却显示 NULL？
这是 LEFT JOIN 的典型表现：右表无匹配行时，聚合函数作用于空集，默认返回 NULL，不是 0。必须显式用 COALESCE(COUNT(...), 0) 或 IFNULL(COUNT(...), 0) 转换。
- 别写
COUNT(col_name)来“规避”——它统计非 NULL 值个数，和补零无关 - 也别用
SUM(CASE WHEN ... THEN 1 ELSE 0 END)替代，语义不清且性能略差 - 如果还要算平均值等指标，记得对
NULL做同样处理，比如COALESCE(AVG(l.duration), 0)
真正容易被忽略的是时区。如果你的原始 event_time 是 UTC，但业务要求按本地时区（如 Asia/Shanghai）每小时统计，必须先转换再截断：DATE_TRUNC('hour', event_time AT TIME ZONE 'UTC' AT TIME ZONE 'Asia/Shanghai') —— 漏掉这步，凌晨时段会整体偏移 8 小时。
