必须先将时间戳向下取整对齐到自定义起点(如每15分钟桶的起始时间),再group by;直接group by原始时间戳无法实现区间分组,且需预处理毫秒与时区,空时间段须用generate_series或递归cte补零。

时间必须先对齐到自定义起点,再 GROUP BY
直接 GROUP BY event_time 不会按“每15分钟”或“每周三零点起”分组,只会按原始值精确匹配。真正要做的是把每个时间戳映射到它所属区间的统一锚点,比如把 2026-07-20 14:12:33 转成 2026-07-20 14:00:00(15分钟桶的起始时间)。关键不是截断,而是向下取整到固定间隔。
必须用 FLOOR,不能用 ROUND 或 CEILING:否则像 14:07:59 和 14:08:00 可能被分到不同桶里,边界错位。
- MySQL:
FROM_UNIXTIME(FLOOR(UNIX_TIMESTAMP(event_time) / 900) * 900)(900 = 15×60) - PostgreSQL:
TO_TIMESTAMP(FLOOR(EXTRACT(EPOCH FROM event_time) / 900) * 900) - SQL Server:
DATEADD(minute, (DATEDIFF(minute, 0, event_time) / 15) * 15, 0)
毫秒和时区不处理,分组就漂移
如果 event_time 带毫秒(如 DATETIME(3))或带时区(TIMESTAMP WITH TIME ZONE),不做预处理,结果不可控。典型现象是同一分钟内的数据被拆成两条记录,比如一条是 09:00:00,另一条是 09:00:00.123——因为毫秒参与了除法运算,FLOOR 结果不同。
实操建议:
- 先去掉毫秒:
CAST(event_time AS DATETIME)(MySQL)、TRUNC(event_time, 'SS')(Oracle) - 时区要显式对齐:
CONVERT_TZ(event_time, '+00:00', '+08:00')(MySQL)、event_time AT TIME ZONE 'Asia/Shanghai'(PostgreSQL) - 确认“每5分钟”是指 UTC 还是本地时间——两者算出来的桶完全不一样
空时间段必须补零,不能靠应用层硬拼
原始表某5分钟没数据,GROUP BY 就不会输出那行。但监控图、SLA报表需要显示 0,否则趋势断层。
正确做法是在 SQL 层生成完整时间序列,再左连聚合结果:
- PostgreSQL:直接用
GENERATE_SERIES('2026-07-20'::date, '2026-07-21'::date, '5 minutes') - MySQL:没有原生
GENERATE_SERIES,得用递归 CTE 或临时数列模拟 - SQL Server 2022+:
GENERATE_SERIES返回整数,需配合DATEADD转时间
重点:子查询里的 WHERE 条件范围必须和外层生成的时间序列一致,否则 LEFT JOIN 会漏掉空桶。
DATE_BUCKET 看起来省事,但别无脑用
SQL Server 2022+ 的 DATE_BUCKET(minute, 5, event_time) 确实简洁,但它有硬伤:
- 版本锁死:旧版 SQL Server、跨库迁移时直接报错
- 不支持时区转换:输入是
TIMESTAMP就按本地时区解释,无法指定'Asia/Shanghai' - 无法处理毫秒:传入
DATETIME2(3)时,内部可能四舍五入,导致边界偏移
真正难的不是写出 GROUP BY DATE_TRUNC('hour', ts),而是确认你的时区上下文是否一致、索引是否被绕过、以及凌晨跨天时夏令时切换是否影响分组边界。










