窗口函数不能替代group by做小时聚合，因其不压缩行数、仅扩展计算列；必须先用group by按小时截断聚合（如date_format或date_trunc），再在聚合结果上用窗口函数进行跨组比较。
窗口函数不能直接替代 GROUP BY 做小时聚合
很多人一看到“按小时统计峰值”就本能想用 ROW_NUMBER() 或 RANK() 加 PARTITION BY HOUR(time_col)，结果发现数据没聚合、行数没变、峰值算不出来——窗口函数本身不压缩行，它只在已有行上打标记。真要得到“每小时一个峰值”，必须先用 GROUP BY HOUR(time_col) 或 DATE_FORMAT(time_col, '%Y-%m-%d %H') 聚合出每小时的统计值（比如 MAX(value)），再在这组聚合结果上用窗口函数做跨小时比较（比如找当天最高小时峰值）。
MySQL 8.0+ 中正确写法：先 GROUP BY 小时，再套窗口
假设表 events 有 created_at 和 load 字段，目标是：每小时最大 load，并标出哪个小时是当天全局峰值。关键点在于两层嵌套：
SELECT
hour_slot,
max_load,
CASE WHEN max_load = MAX(max_load) OVER() THEN 'peak' ELSE '' END AS is_daily_peak
FROM (
SELECT
DATE_FORMAT(created_at, '%Y-%m-%d %H:00:00') AS hour_slot,
MAX(load) AS max_load
FROM events
WHERE created_at >= '2024-06-01'
GROUP BY DATE_FORMAT(created_at, '%Y-%m-%d %H:00:00')
) AS hourly
ORDER BY hour_slot;
注意：DATE_FORMAT 比 HOUR() 更安全，后者只返回 0–23，会跨天混掉；MAX(max_load) OVER() 是对子查询结果集整体取最大，不是按小时分区。
PostgreSQL 和 SQL Server 的时间截断差异
不同数据库截断到小时的方式不同，直接影响 GROUP BY 分组逻辑：
- PostgreSQL：用
DATE_TRUNC('hour', created_at)，返回带时区的 timestamp，分组稳定 - SQL Server：用
DATEADD(HOUR, DATEDIFF(HOUR, 0, created_at), 0)，避免CONVERT截断精度丢失 - SQLite：没有原生小时截断，得用
strftime('%Y-%m-%d %H:00:00', created_at)
如果用错截断方式（比如 PostgreSQL 里误用 EXTRACT(HOUR FROM created_at)），会导致所有同小时但不同日期的数据被合到一起，峰值统计完全失真。
性能陷阱：WHERE 条件必须下推到内层
窗口函数本身不走索引，但外层窗口不影响执行计划；真正拖慢的是没加时间范围过滤的全表扫描。常见错误是把 WHERE 放在外层：
-- ❌ 危险：先全表 GROUP BY，再过滤，可能扫千万行 SELECT * FROM (SELECT ..., MAX(load) FROM events GROUP BY ...) t WHERE hour_slot > '2024-06-01';
正确做法是 WHERE 必须写在最内层聚合前：
-- ✅ 索引能生效（只要 created_at 有索引） SELECT ... FROM (SELECT ... FROM events WHERE created_at >= '2024-06-01' GROUP BY ...) t;
另外，如果小时粒度下数据稀疏（比如每小时只有几条），MAX() 很快；但若某小时有上万事件，MAX() 仍需遍历该小时全部行——这时考虑是否真需要精确峰值，还是可用采样或近似算法。
窗口函数本身不解决聚合问题，它只解决“在已聚合的结果上加横向比较”。漏掉 GROUP BY 这一步，或者把时间截断写错，后面全白搭。
