MySQL中GROUP BY HOUR()“少一小时”实为未对齐小时边界，正确做法是用DATE_FORMAT(..., '%Y-%m-%d %H:00:00')截断或GROUP BY DATE(), HOUR()，并注意TIMESTAMP/DATETIME时区差异。
GROUP BY HOUR() 在 MySQL 中为什么总少一小时
MySQL 的 HOUR() 函数直接取当前时间的小时数（0–23），但如果你用它做按小时分组，常会发现 00:00–00:59 的数据被归到 0 小时，而你真正想对齐的是“每整点开始的 60 分钟窗口”，比如 14:00–14:59 应该统一标为 "14"。问题不在函数本身，而在你没把时间对齐到小时边界。
- 错误写法：
GROUP BY HOUR(created_at)—— 忽略了日期部分，跨天数据会被混在一起 - 正确做法：先用
DATE_FORMAT(created_at, '%Y-%m-%d %H:00:00')截断到小时精度，再分组 - 更稳妥的写法是：
GROUP BY DATE(created_at), HOUR(created_at)，避免跨日聚合失真 - 注意时区：如果
created_at是TIMESTAMP类型，MySQL 会自动转成系统时区再计算HOUR()；如果是DATETIME，则不转换——这点极易导致线上和本地结果不一致
PostgreSQL 怎么按 UTC+8 小时窗口汇总
PostgreSQL 没有内置的 HOUR() 时间截断函数，直接用 EXTRACT(HOUR FROM created_at) 同样会丢失日期上下文，且默认按服务器时区解析。要稳定按东八区每小时汇总，必须显式时区转换。
- 关键操作：用
created_at AT TIME ZONE 'UTC' AT TIME ZONE 'Asia/Shanghai'先转成北京时间，再截断 - 推荐分组表达式：
DATE_TRUNC('hour', created_at AT TIME ZONE 'UTC' AT TIME ZONE 'Asia/Shanghai') - 别用
EXTRACT(HOUR FROM ...)单独分组——它只返回数字，无法区分 2023-01-01 14:00 和 2023-01-02 14:00 - 如果表里存的是字符串时间（如
'2023-01-01T14:22:03'），先用TO_TIMESTAMP(col, 'YYYY-MM-DD"T"HH24:MI:SS')转成TIMESTAMP WITH TIME ZONE再处理
WHERE 条件写在 GROUP BY 前还是后？性能差十倍
时间序列分析常要查最近 7 天、每小时的请求量。如果在 GROUP BY 后用 HAVING 过滤小时粒度的聚合结果，等于全表先聚合再筛，索引基本失效。
- 必须把时间范围条件放在
WHERE子句：WHERE created_at >= NOW() - INTERVAL '7 days' - 确保
created_at字段上有索引；若用函数包装（如DATE(created_at)），索引大概率失效 - PostgreSQL 中，如果用了
AT TIME ZONE转换，索引仍可用，前提是原字段是TIMESTAMP WITH TIME ZONE且查询条件也带时区上下文 - MySQL 8.0+ 支持函数索引，可建：
CREATE INDEX idx_hour ON tbl (DATE(created_at), HOUR(created_at))加速分组
NULL 时间值导致整组消失怎么办
只要 created_at 为 NULL，那行数据在 GROUP BY 后就彻底不可见——不会归入某小时，也不会单独成一组。这在埋点日志或异步任务表中极常见，容易造成总量对不上。
- 检查空值占比：
SELECT COUNT(*) FILTER (WHERE created_at IS NULL) FROM tbl（PG）或SUM(IF(created_at IS NULL, 1, 0))（MySQL） - 想保留空值组：用
COALESCE(created_at, '1970-01-01 00:00:00')替换，但需同步在WHERE中排除它，否则污染正常数据 - 更合理做法是单独统计：
SELECT 'null_time' AS hour_bin, COUNT(*) FROM tbl WHERE created_at IS NULL，再和主查询UNION ALL - 上线前务必确认业务是否允许丢弃空时间数据——有些监控场景里，空时间本身就代表采集异常，不该进小时统计
事情说清了就结束
