必须向下取整分组：PostgreSQL/Redshift用DATE_TRUNC配合INTERVAL偏移，MySQL/ClickHouse等用FLOOR(UNIX_TIMESTAMP(ts)/300)*300；需统一转UTC防时区错位；WHERE应覆盖完整时间桶而非仅起点。
用 FLOOR 或 DATE_TRUNC 对时间戳做向下取整分组
直接对 timestamp 字段做聚合前，必须先把它“掰成”固定间隔的桶。主流数据库有两种常用方式：PostgreSQL/Redshift 用 DATE_TRUNC('minute', ts) 配合 INTERVAL 偏移；MySQL 8.0+ 和大多数其他引擎（包括 ClickHouse、Trino）更依赖 FLOOR(UNIX_TIMESTAMP(ts) / 300) * 300 这类算术截断——300 就是 5 分钟的秒数。
注意别用 ROUND，它会把 00:04:59 和 00:05:01 都归到同一组，但实际你想的是「每 5 分钟一个窗口，从整点开始」，所以必须向下取整。
- PostgreSQL 示例：
GROUP BY DATE_TRUNC('minute', ts) - INTERVAL '1 minute' * (EXTRACT(MINUTE FROM ts) % 5)（更稳妥的偏移写法） - MySQL/ClickHouse：
GROUP BY FROM_UNIXTIME(FLOOR(UNIX_TIMESTAMP(ts) / 300) * 300) - BigQuery：
GROUP BY TIMESTAMP_TRUNC(ts, MINUTE, 'UTC') - MOD(EXTRACT(MINUTE FROM ts), 5) * INTERVAL 1 MINUTE
避免跨时区导致的聚合错位
如果原始数据里 ts 是 TIMESTAMP WITHOUT TIME ZONE 或字符串，又没明确标注时区，DATE_TRUNC 很可能按服务器本地时区解释，结果每 5 分钟桶在不同时区看起来完全错开。最稳的做法是统一转成 UTC 再截断。
- PostgreSQL：
GROUP BY DATE_TRUNC('minute', ts AT TIME ZONE 'UTC') - MySQL：
GROUP BY CONVERT_TZ(ts, @@session.time_zone, '+00:00')再套FROM_UNIXTIME(FLOOR(...)) - 千万别直接对
NOW()或CURRENT_TIMESTAMP做同样处理——它们默认带时区，但和你数据字段的时区假设可能不一致
WHERE 条件要覆盖完整时间桶，不能只写起点
如果只想查「今天 09:00 到 10:00 的每 5 分钟聚合」，别写 WHERE ts >= '09:00' AND ts —— 这会漏掉 09:55:00 到 09:59:59 的数据，因为它们属于 09:55 这个桶，但你的上限条件把它拦在外面了。
- 正确做法是把 WHERE 范围扩到桶边界：比如查 09:00–10:00 的桶，实际应查
ts >= '09:00' AND ts - 或者更安全：用截断后的时间字段过滤，如
WHERE DATE_TRUNC('minute', ts) >= '09:00' AND DATE_TRUNC('minute', ts) - 这个细节在实时看板里特别容易出问题——前端选了 09:00–10:00，后端没扩展范围，最后一分钟的聚合就永远空着
窗口函数无法替代 GROUP BY 实现真·固定频率聚合
有人试过用 OVER (ORDER BY ts RANGE BETWEEN INTERVAL '4 minutes' PRECEDING AND CURRENT ROW) 想模拟滑动 5 分钟窗口，但这不是「每 5 分钟一个桶」，而是每个行都拉一个向前 5 分钟的数据集，结果行数和原始表一样多，且桶之间重叠严重。真正需要的是离散、不重叠、等宽的桶。
-
GROUP BY+ 时间截断是唯一能生成「每 5 分钟一行」结果的方式 - 窗口函数适合计算滚动指标（比如“当前时刻过去 5 分钟平均值”），不适合生成时间序列图表的横轴刻度
- 如果硬要用窗口函数强行对齐桶，得再套一层
DISTINCT ON或子查询去重，性能差且逻辑绕远
最常被忽略的是时区对齐和 WHERE 边界——这两处一错，聚合结果看着正常，但相邻时间段的数据会莫名少一条或重复一条，排查起来要翻日志比对原始时间戳。
