活跃峰值指在指定滑动时间窗口内同一分组并发出现的最多记录数，用于实时监控在线状态等场景，需基于时间范围JOIN而非行偏移计算，并依赖group_id+event_time复合索引提升性能。
什么是“活跃峰值”在滑动窗口里的实际含义
活跃峰值不是简单求 COUNT(*) 或 MAX()，而是指：在指定时间窗口（比如过去 30 分钟）内，同一分组下并发出现的最多记录数。典型场景是实时监控用户在线状态、设备心跳、API 请求流——你需要知道“某个服务在最近一小时里最高同时在线多少台设备”，而不是“一小时内总共上报了多少次”。
用窗口函数 + 时间对齐实现近似峰值（PostgreSQL / MySQL 8.0+）
严格意义上的滑动峰值需流式计算，但多数 OLAP 场景可用“离散时间桶 + 窗口累计”逼近。关键是把时间切片对齐，再统计每个桶内各分组的记录数，最后取最大值。
常见错误是直接 GROUP BY time_bucket, group_id 后套 MAX(count)——这只能得到每个桶内的最大值，而非跨桶重叠窗口的峰值。
- 先用
time_bucket('5 minutes', event_time)（PostgreSQL TimescaleDB）或FLOOR(UNIX_TIMESTAMP(event_time) / 300)（MySQL）做固定粒度分桶 - 对每个分组，用
ROW_NUMBER() OVER (PARTITION BY group_id ORDER BY event_time)标记顺序，再自连接或 LATERAL JOIN 模拟滑动：查当前行往前 N 分钟的所有行 - 更实用的做法：生成辅助时间序列表，与原始表 LEFT JOIN ON
t1.group_id = t2.group_id AND t2.event_time BETWEEN t1.event_time - INTERVAL '30 minutes' AND t1.event_time，再GROUP BY t1.group_id, t1.event_time后COUNT(*)，最后MAX()
避免用 LAG() / LEAD() 直接算滑动峰值
这两个函数只看相邻行，无法覆盖任意长度的时间窗口。比如你想查“过去 1 小时内最大并发数”，而数据间隔不均（有的 2 秒一次，有的 5 分钟才来一条），LAG(event_time, 60) 完全不可靠——它拉的是第 60 行，不是 60 分钟前那行。
正确做法必须基于时间表达式过滤，而非行偏移。MySQL 中尤其注意：TIMESTAMPDIFF(MINUTE, prev_time, curr_time) 不可替代真实范围 JOIN；PostgreSQL 中 event_time >= current_timestamp - INTERVAL '30 minutes' 才是安全边界。
性能关键点：索引和分区必须包含时间 + 分组字段
没有复合索引，滑动窗口 JOIN 会全表扫描，100 万行就卡死。必须建：
CREATE INDEX idx_group_time ON events (group_id, event_time);
如果表极大，还要按时间分区（如 PostgreSQL 的 PARTITION BY RANGE (event_time) 或 MySQL 的 ALTER TABLE events PARTITION BY RANGE COLUMNS(event_time)）。只按时间分区不够——没加 group_id，查询单个分组时仍要扫所有分区。
另外，event_time 字段类型必须是 TIMESTAMP 或 TIMESTAMPTZ，别用 VARCHAR 存时间字符串，否则索引失效、范围查询变全表。
滑动窗口峰值的本质是“时间维度上的局部密度测量”，它天然依赖高效的时间范围检索能力。想绕过索引硬算，等于在生产环境开盲盒。
