用 date_trunc() 实现5分钟时间桶聚合需先转epoch秒数、除以300取整、再转回时间戳，即 to_timestamp(floor(extract(epoch from ts) / 300) * 300)；generate_series() 仅适合补全零值桶，tsrange+overlaps 不适用于高效分组，时区不一致是边界偏移主因。
用 date_trunc() 实现 5 分钟时间桶聚合
PostgreSQL 没有原生的“每 5 分钟分组”语法，但 date_trunc() 是最直接、最可靠的方式。它把时间截断到指定精度，再配合算术偏移就能对齐到 5 分钟边界（比如 00:00、00:05、00:10…）。
关键点在于：不能只写 date_trunc('minute', ts)，那只会截到分钟级（即每分钟一桶）；必须把时间先转成 epoch 秒数，除以 300（5×60），取整后再转回时间戳。
实操建议：
- 对
timestamp或timestamptz字段，用EXTRACT(EPOCH FROM ts)转为秒数 - 用
FLOOR(EXTRACT(EPOCH FROM ts) / 300)得到每 5 分钟一个整数 ID - 再用
TO_TIMESTAMP()把这个 ID 变回时间戳，就是该桶的起始时间 - 完整表达式：
TO_TIMESTAMP(FLOOR(EXTRACT(EPOCH FROM ts) / 300) * 300)
示例（统计每 5 分钟的请求量）：
SELECT TO_TIMESTAMP(FLOOR(EXTRACT(EPOCH FROM created_at) / 300) * 300) AS bucket, COUNT(*) AS cnt FROM logs WHERE created_at >= '2024-06-01' GROUP BY bucket ORDER BY bucket;
为什么不用 generate_series() 做时间桶？
generate_series() 确实能生成等间隔时间序列，但它适合「补全缺失桶」场景，而不是替代分组逻辑。如果直接用它 JOIN 原表做聚合，容易因时区、边界对齐或 NULL 处理出错，性能也更差。
常见错误现象：
- JOIN 后出现大量
NULL行，误以为有数据缺失（其实是时间没对齐） - 用
timestamptz时未显式转换时区，导致桶起始时间漂移（比如本该是 UTC+8 的 09:00–09:05，结果按 UTC 算成了 01:00–01:05） - 没加
WHERE过滤原始数据时间范围，导致generate_series()生成了海量无意义桶
只有当你明确需要「强制显示所有 5 分钟区间（含零值）」时，才在 date_trunc() 聚合结果基础上 LEFT JOIN generate_series() 补空。
tsrange + OVERLAPS 不适合常规聚合
有人尝试用时间范围类型（tsrange）配合 OVERLAPS 判断归属，这在小数据量、单条记录匹配时可行，但无法高效用于 GROUP BY。PostgreSQL 无法在 GROUP BY 中直接使用动态 range 表达式，会报错 column "xxx" must appear in the GROUP BY clause or be used in an aggregate function。
性能影响明显：
- 每个行都要构造两个
tsrange并计算重叠，CPU 开销大 - 无法利用时间字段上的 B-tree 索引加速（range 操作走的是 gist/gin，且对聚合无效）
- 语义易混淆：5 分钟桶是左闭右开 [
09:00,09:05)，而OVERLAPS是闭区间判断，边界行为不一致
时区和字段类型不匹配的坑
聚合结果看起来“偏了 1 小时”或“桶边界不对”，90% 是时区搞混了。重点检查三处：
- 原始字段类型：是
timestamp without time zone还是timestamptz？前者不带时区信息，date_trunc()按数据库timezone设置解释；后者会自动转为当前会话时区再截断 - 会话时区是否设对：
SHOW timezone;，必要时用SET timezone = 'Asia/Shanghai'; - 客户端连接字符串里是否隐式覆盖了时区（如 JDBC 的
serverTimezone=GMT%2B8）
最稳妥的做法：统一用 timestamptz 存储，聚合前显式转成所需时区再截断，例如：(created_at AT TIME ZONE 'Asia/Shanghai')。
真正麻烦的不是写法本身，而是不同环节对“同一时间”的解释不一致——数据库、应用、监控系统各自用的时区可能不同，聚合结果一旦上线就很难回溯修正。
