直接按时间戳group by会漏掉相邻日志，因高精度时间戳存在毫秒抖动，导致同一逻辑窗口日志被拆分；需用date_trunc等函数向下对齐到整点/整分再聚合。
为什么直接用 GROUP BY 时间戳会漏掉相邻日志？
因为原始日志时间戳（比如 2024-05-22 14:36:42.891）精度高、无规律，直接按秒或分钟 GROUP BY 会导致同一逻辑窗口内的多条日志被拆到不同分组——尤其当服务写入存在毫秒级抖动时。真正需要的是“向下对齐到整点/整分”，再聚合。
用 DATE_TRUNC 或时间截断函数做对齐（PostgreSQL / BigQuery）
DATE_TRUNC 是最直接的对齐手段，它把时间向下舍入到指定粒度的起点。注意不是四舍五入，也不是向上取整，这点常被误用。
常见用法：
-
DATE_TRUNC('hour', log_time)→ 对齐到小时初，如2024-05-22 14:00:00 -
DATE_TRUNC('minute', log_time)→ 对齐到分钟初，如2024-05-22 14:36:00 -
DATE_TRUNC('5 minutes', log_time)（PostgreSQL 14+）→ 对齐到最近的 5 分钟边界（...:00、...:05等）
示例：统计每 5 分钟的错误数
SELECT
DATE_TRUNC('5 minutes', log_time) AS window_start,
COUNT(*) FILTER (WHERE level = 'ERROR') AS error_count
FROM logs
WHERE log_time >= NOW() - INTERVAL '1 hour'
GROUP BY DATE_TRUNC('5 minutes', log_time)
ORDER BY window_start;
MySQL / SQL Server 怎么办？没有 DATE_TRUNC
MySQL 8.0+ 可用 DATE_SUB(log_time, INTERVAL SECOND(log_time) SECOND) 手动截断到分钟；更通用的做法是用整数运算“归一化”：
- 对齐到分钟：
FROM_UNIXTIME(FLOOR(UNIX_TIMESTAMP(log_time) / 60) * 60) - 对齐到 10 分钟：
FROM_UNIXTIME(FLOOR(UNIX_TIMESTAMP(log_time) / 600) * 600) - SQL Server 类似：
DATEADD(MINUTE, DATEDIFF(MINUTE, 0, log_time), 0)（对齐到分钟），再套一层除法可做自定义周期
注意：UNIX_TIMESTAMP 返回秒数，务必确认时区一致；若字段是 DATETIME 且含毫秒，先 CAST(log_time AS DATETIME2(0)) 避免浮点误差。
对齐后聚合仍不准？检查时区和数据倾斜
两个隐形坑：
- 日志时间字段是
TIMESTAMP WITHOUT TIME ZONE，但应用写入时没统一转 UTC，导致同一物理分钟在数据库里散落在多个对齐窗口 - 高频日志集中在某几秒（如批量上报），而对齐窗口恰好卡在秒边界上，造成单个窗口数据量突增，掩盖真实分布
建议：聚合前加 WHERE log_time AT TIME ZONE 'UTC'（PostgreSQL）或显式转换，再对齐；若需观察“窗口内最大并发量”，别只用 COUNT(*)，改用 APPROX_COUNT_DISTINCT(client_id) 或滑动采样。
对齐本身很简单，难的是确认原始时间是否可信、时区是否已归一、以及你真正想回答的问题是不是“每 N 分钟发生了什么”——有时候按请求 ID 或 trace_id 分组，比按时间硬切更接近业务语义。
