必须先将时间截断到整点（如'2024-05-20 14:37:22'→'2024-05-20 14:00:00'），再按截断后时间分组并用ROW_NUMBER()取每小时流量峰值行，否则仅用HOUR()会跨天错误聚合。
用 ROW_NUMBER() 按小时分组取峰值行，核心是先截断时间再排序
直接按原始时间戳排序再 ROW_NUMBER() 会跨小时混排，必须先把时间归到整点。比如 '2024-05-20 14:37:22' 要转成 '2024-05-20 14:00:00' 才能正确分组。
不同数据库截断方式略有差异：
- PostgreSQL / MySQL 8.0+：用
DATE_TRUNC('hour', event_time)或DATE_FORMAT(event_time, '%Y-%m-%d %H:00:00') - SQL Server：用
DATEADD(HOUR, DATEDIFF(HOUR, 0, event_time), 0) - SQLite：用
strftime('%Y-%m-%d %H:00:00', event_time)
归整后，再对每小时内的记录按流量字段（如 bytes）降序排，ROW_NUMBER() OVER (PARTITION BY hour_slot ORDER BY bytes DESC) 就能标出每小时最大值所在行。
为什么不能只用 GROUP BY HOUR(event_time)？
HOUR(event_time) 只返回 0–23 的数字，丢失了日期信息，会导致“今天 14 点”和“昨天 14 点”被合并在同一组——这不是你想要的每小时独立峰值。
真正需要的是带日期的完整小时槽位，例如：
- ✅
'2024-05-20 14:00:00' - ❌
14（无日期，跨天聚合）
所以必须用带日期的时间截断函数，而不是单纯提取小时数。
峰值统计结果里要不要保留原始时间戳？
要。仅靠 hour_slot 只知道是哪一小时，但不知道峰值具体发生在该小时内的哪个时刻。实际排查时，运维或产品常需要定位到秒级时间点。
写法上别只选 hour_slot 和 bytes，记得带上原始字段：
SELECT
hour_slot,
event_time, -- 原始时间，精确到秒
bytes,
user_id
FROM (
SELECT
DATE_TRUNC('hour', event_time) AS hour_slot,
event_time,
bytes,
user_id,
ROW_NUMBER() OVER (
PARTITION BY DATE_TRUNC('hour', event_time)
ORDER BY bytes DESC
) AS rn
FROM traffic_log
) t
WHERE rn = 1;注意：如果某小时内有多个相同最大 bytes 值，默认按 event_time 稳定性不确定，可追加 , event_time ASC 避免非确定性结果。
当流量表超大时，ROW_NUMBER() 性能很卡怎么办？
全表加窗口函数会强制扫描并排序所有数据，即使只取每小时 top 1。优化方向有两个：
- 给
event_time建索引（必备），让时间截断能快速定位范围 - 改用两阶段聚合：先
GROUP BY hour_slot求出每小时MAX(bytes)，再用子查询关联回原表找匹配行（需注意多值冲突）
后者在千万级以上表中通常快 3–5 倍，但代码稍长；前者逻辑直白，适合中小规模或调试阶段。
真实场景里，小时峰值往往还要叠加维度（如按 region 或 endpoint），这时 PARTITION BY 就得包含这些字段，且组合索引顺序很重要——时间字段建议放最左。
