必须先将时间戳向下取整对齐到自定义起点（如每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)，而是确认你的时区上下文是否一致、索引是否被绕过、以及凌晨跨天时夏令时切换是否影响分组边界。
