统计某小时内任意时刻的最大并发连接数，这事儿可真不是简单地对连接时间按小时分组、再数个数就能搞定的。你得把每条连接的生命周期——也就是连接建立时间和断开时间——拆解成按小时为单位的重叠区间，然后统计每个小时窗口内的最大值。而且，必须把连续的小时序列补全，再用范围连接去匹配，不然那些刚好卡在临界点上的连接就会被漏算。
用 DATE_TRUNC 或 DATEPART 对连接时间做小时对齐
核心思路是还原「某小时内任意时刻同时在线的最大连接数」。具体做法，就是把每条连接的 connect_time 和 disconnect_time 拆成按小时粒度的重叠区间。不同数据库的操作略有差异：PostgreSQL 直接用 DATE_TRUNC('hour', connect_time) 就能截断到小时起点；SQL Server 需要 DATEPART 配合拼接函数；MySQL 8.0+ 虽然支持 DATE_SUB，但更稳妥的办法是用 FLOOR(UNIX_TIMESTAMP(connect_time) / 3600) 转成小时戳——这样做可以避免时区或日期函数行为差异带来的错位。
生成每小时的时间点序列并关联连接生命周期
千万别只查原始表里出现过的那些小时，必须把目标时间段内所有连续的小时点都补全，否则空闲时间段的数据会凭空消失。常规做法是用递归 CTE 或数字表生成小时序列，再与连接日志做范围连接。例如在 PostgreSQL 中：
WITH hours AS ( SELECT generate_series( '2024-01-01 00:00'::timestamp, '2024-01-02 00:00'::timestamp, '1 hour'::interval ) AS hour_start)SELECT h.hour_start, (SELECT COUNT(*) FROM connections c WHERE c.connect_time <= h.hour_start + '1 hour'::interval AND c.disconnect_time > h.hour_start) AS concurrent_countFROM hours h;
这里有一个关键点：条件必须是 c.connect_time <= h.hour_start + '1 hour' 且 c.disconnect_time > h.hour_start，这样才能准确捕获到在该小时区间内「至少重叠了一瞬」的所有连接。等号方向或条件逻辑要是反了，临界连接就会被漏算。
避免用 COUNT(*) OVER (PARTITION BY ...) 直接分组
这是最容易被踩进去的坑。很多人会直接对原始连接记录按小时分组，然后数个数——但那样得到的是「该小时新建连接数」，根本不是并发数。并发是一个动态叠加的过程：同一条连接可能跨越多个小时，比如一个用户在 13:59 连入、14:01 断开，它应该同时计入 13 点和 14 点的并发基数。如果强行用窗口函数或分组聚合，时间维度上的覆盖关系就会丢失。必须把单条连接展开成它影响到的每一个小时槽位（哪怕只占了其中的几秒钟），再对每个槽位做计数。
性能瓶颈通常卡在范围连接和数据量上
当连接日志行数超过百万时，上述范围 JOIN 马上就会变得非常慢。优化思路主要有三条：
- 给
connect_time和disconnect_time建复合索引：CREATE INDEX idx_conn_time ON connections(connect_time, disconnect_time) - 预计算每条连接影响的起止小时戳（用两个整型字段存储），用整数范围查询替代时间计算
- 改用事件驱动法：把连接和断开视为 +1/-1 事件，按时间排序后做变量累计，再每小时取累计值的最大值——这需要数据库支持变量或窗口函数（如 MySQL 8.0+、PostgreSQL 14+）
最后一种方法在处理大数据量时性能会提升一个数量级，但逻辑稍微复杂一些，而且如果断开事件缺失，累计值可能会出错。
其实，真正让这件事变得困难的不是写 SQL 语句本身，而是你得先确认日志中的 disconnect_time 是否可靠。很多系统只记录连接时间，断开时间是由超时机制推断出来的，这种情况下的峰值只能估算。所以，补全断开时间才是前置条件——先解决数据质量，再谈按小时统计。
