用 FLOOR 和时间单位换算实现 5 分钟分组
直接对 timestamp 字段下手做整除？行不通的。数据库压根不让你直接对时间类型做四则运算。真正的做法是：先把时间戳转化成秒数（Unix时间戳），除以300（5×60），然后用 FLOOR 截断到最近的5分钟起点，最后再转回可读的时间格式。
不同数据库的函数名虽然各不相同，但内在逻辑完全一致：
- PostgreSQL：
FLOOR(EXTRACT(EPOCH FROM ts) / 300)，再用TO_TIMESTAMP转回 - MySQL：
FLOOR(UNIX_TIMESTAMP(ts) / 300)，配合FROM_UNIXTIME - SQL Server：
DATEDIFF(second, '1970-01-01', ts) / 300，注意整除自动向下取整 - ClickHouse：
FLOOR(toUnixTimestamp(ts) / 300)，搭配fromUnixTimestamp
这个套路很清晰，但接下来要小心几个容易翻船的地方。
避免 GROUP BY 中时间精度丢失
如果你只是用 FLOOR(...)/300 做了分组操作，结果里显示的就是一长串数字（比如 1712345678），看起来十分混乱。必须用对应的函数把这些数字还原成可读时间——而且，这个转换表达式必须和 GROUP BY 中的表达式完全一致，否则要么报错，要么分组逻辑全乱套。
实际踩坑时，最常见的错误是：分组时写的是 FROM_UNIXTIME(FLOOR(UNIX_TIMESTAMP(ts)/300)*300)，而 SELECT 里却写成了 DATE_FORMAT(...) 或者干脆忘了乘以300。两者不等价，结果自然对不上。
- MySQL 的正确写法：
GROUP BY FLOOR(UNIX_TIMESTAMP(ts)/300)，SELECT 里用FROM_UNIXTIME(FLOOR(UNIX_TIMESTAMP(ts)/300) * 300) - PostgreSQL 必须确保
TO_TIMESTAMP(FLOOR(EXTRACT(EPOCH FROM ts)/300) * 300)和 GROUP BY 表达式严格一致 - 别用
DATE_TRUNC('minute', ts)来替代——它只能截到整分钟，没法按5分钟对齐
这个细节一旦忽略，后面查数据查得怀疑人生。
时区问题会让 5 分钟区间偏移
所有时间戳函数默认使用的是数据库所在的时区（比如UTC或系统本地时间）。如果你的数据是北京时间（UTC+8），而数据库设为UTC，那么计算出的5分钟边界就会是UTC时间，和业务理解的“每小时00/05/10…分”完全对不上。
- MySQL：确保
ts字段是TIMESTAMP类型（支持时区转换），而不是DATETIME - PostgreSQL：用
ts AT TIME ZONE 'Asia/Shanghai'先转时区，再提取epoch - ClickHouse：
toTimeZone(ts, 'Asia/Shanghai')配合toUnixTimestamp - 快速验证方法：取一个已知时间点（如
'2024-04-05 10:07:22'），手动计算它应该归属于哪个5分钟区间（应该是10:05:00），然后对比SQL输出
时区问题常常在数据写入时就已埋下隐患，后期排查非常头疼。
性能注意：别在 WHERE 条件里对字段做函数转换
如果写 WHERE FLOOR(UNIX_TIMESTAMP(ts)/300) = FLOOR(UNIX_TIMESTAMP('2024-04-05 10:05:00')/300)，后果就是全表扫描——索引失效了，性能直接崩盘。
正确的做法是把目标区间换算成时间范围：
WHERE ts >= '2024-04-05 10:05:00' AND ts < '2024-04-05 10:10:00'
这样能直接走 ts 字段上的索引。如果查询非常频繁，建议额外创建一个生成列（比如 ts_5min_bucket）并给它建上索引，能大幅提升性能。
以上就是把时间戳按5分钟分组的常规套路。不过，真正棘手的不是怎么写代码，而是需要确认数据是否有跨时区写入、有没有 NULL 或非法时间值——这些情况会在 EXTRACT 或 UNIX_TIMESTAMP 时静默失败或返回0，悄无声息地污染你的分组结果。处理时间窗口，小心驶得万年船。
