用 date_trunc('minute', event_time) 将时间戳对齐到分钟边界，再 group by 实现按分钟聚合；需先 where 过滤再截断分组，避免 having 误用；查峰值分钟应结合 95 分位基线与最小日志量过滤。
如何用 DATE_TRUNC 按分钟切分时间戳（PostgreSQL / ClickHouse）
直接用 GROUP BY 原始时间戳肯定不行——每条日志毫秒级不同，根本聚不到一起。关键得把时间“向下对齐”到分钟边界。
PostgreSQL 和 ClickHouse 都支持 DATE_TRUNC('minute', <code>event_time)，它会把 '2024-05-20 14:23:47.123' 变成 '2024-05-20 14:23:00'，所有该分钟内的记录就归到同一组。
- 别用
EXTRACT+ 拼接，容易出时区错，且性能差 - 如果字段是字符串，先用
TO_TIMESTAMP或parseDateTimeBestEffort转成时间类型再截断 - MySQL 用户注意：没有原生
DATE_TRUNC，得用FROM_UNIXTIME(FLOOR(UNIX_TIMESTAMP(<code>event_time) / 60) * 60)
怎么查出峰值分钟（不是简单 ORDER BY COUNT(*) DESC LIMIT 1）
只取最大值容易误判——比如某分钟因采样异常或脏数据突然飙高，实际业务没那么大流量。得加过滤和上下文。
推荐写法：先聚合，再用窗口函数算移动平均或百分位作为基线，最后筛选显著偏离的点。
- 用
PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY cnt)算 95 分位数，排除长尾噪声 - 加
HAVING COUNT(*) > 10过滤掉日志量太少的分钟（避免单条错误日志拉高数值） - 如果想看连续峰值，可加
LAG(cnt) OVER (ORDER BY minute_ts)判断是否比前一分钟高 300%
为什么 WHERE 条件要放在聚合前，而不是 HAVING
常见错误：把过滤条件（如 status = 200）写在 HAVING 里，导致先全表聚合再筛，慢且内存爆。
正确顺序永远是：过滤 → 截断 → 分组 → 聚合 → 再筛（仅必要时）。
-
WHERE status IN (200, 201, 302)必须在GROUP BY前，减少参与聚合的数据量 -
HAVING COUNT(*) > 100是合理用法，但它是对已聚合结果的二次筛选 - 时间范围务必用
WHERE event_time >= '2024-05-20' AND event_time ，别依赖函数索引（多数数据库不走索引）
聚合后怎么快速定位那分钟发生了什么
光知道 '14:23' 流量高没用，得立刻查原始日志看请求特征。别手动复制时间再查——直接嵌套子查询或 CTE 关联原始表。
例如：
WITH peak AS (
SELECT DATE_TRUNC('minute', event_time) AS m
FROM logs
WHERE event_time >= '2024-05-20 14:00'
AND event_time
- 加
AND status != 200能快速发现是否是错误激增引发的假峰值 - 别在外部工具里导出再分析——延迟高，且可能漏掉并发细节
- 如果日志量极大，考虑提前建好按分钟分区的物化视图，否则每次跑都扫全表
真正难的不是聚合语法，而是区分“真实业务高峰”和“采集抖动/重试风暴/探测请求”。得结合状态码分布、URL 路径熵值、客户端 IP 离散度一起看，单靠计数容易误判。
