MySQL并发呼叫计算问题：时间取整后计数异常

我完全懂你碰到的这个坑——把呼叫的开始/结束时间取整到分钟后，直接统计并发数很容易出现偏差，毕竟很多呼叫是跨分钟的，取整后的时间边界处理不好就会错。我给你一套清晰又高效的解决方案，核心是用「事件驱动」的思路来计算，避免边界误判。

为什么直接取整统计会出错？ #

举个例子：一个呼叫从10:01:30开始，到10:03:20结束。取整后变成10:01开始、10:03结束。如果直接用「统计当前分钟内开始且未结束的呼叫」逻辑，会漏掉这个呼叫在10:02分钟的并发状态；或者如果你的判断条件写得不对，又可能重复计数。本质是取整后的时间丢失了精确的时间点信息，导致边界判断逻辑失效。

正确的实现思路 #

把每个呼叫拆成两个明确的时间事件：

• 呼叫开始的分钟点：并发数**+1**（表示新增一个并发呼叫）
• 呼叫结束的分钟点：并发数**-1**（表示减少一个并发呼叫）
  然后按时间顺序遍历这些事件，累加得到每个分钟的实时并发数。这个方法逻辑直观，而且能高效处理大量数据（只要时间字段有索引）。

具体SQL代码（MySQL 8.0+） #

WITH time_events AS (
    -- 生成开始事件：将Starttime取整到分钟，并发数+1
    SELECT
        DATE_FORMAT(Starttime, '%Y-%m-%d %H:%i:00') AS event_minute,
        1 AS delta
    FROM calls
    UNION ALL
    -- 生成结束事件：将Endtime取整到分钟，并发数-1
    SELECT
        DATE_FORMAT(Endtime, '%Y-%m-%d %H:%i:00') AS event_minute,
        -1 AS delta
    FROM calls
),
cumulative_concurrent AS (
    -- 按分钟排序，累加delta得到每个时间点的实时并发数
    SELECT
        event_minute,
        SUM(delta) OVER (ORDER BY event_minute) AS current_concurrent
    FROM time_events
)
-- 按分钟分组，取该分钟内的最大并发数（即分钟峰值）
SELECT
    event_minute,
    MAX(current_concurrent) AS peak_concurrent_calls
FROM cumulative_concurrent
GROUP BY event_minute
ORDER BY event_minute;

兼容低版本MySQL（8.0以下）的写法 #

如果你的MySQL不支持窗口函数，可以用用户变量实现累加：

SELECT
    event_minute,
    MAX(current_concurrent) AS peak_concurrent_calls
FROM (
    SELECT
        event_minute,
        @current := @current + delta AS current_concurrent
    FROM (
        -- 生成所有时间事件
        SELECT
            DATE_FORMAT(Starttime, '%Y-%m-%d %H:%i:00') AS event_minute,
            1 AS delta
        FROM calls
        UNION ALL
        SELECT
            DATE_FORMAT(Endtime, '%Y-%m-%d %H:%i:00') AS event_minute,
            -1 AS delta
        FROM calls
        ORDER BY event_minute
    ) AS events
    CROSS JOIN (SELECT @current := 0) AS init
) AS cumulative
GROUP BY event_minute
ORDER BY event_minute;

优化小贴士 #

• 给Starttime和Endtime字段添加索引，这样DATE_FORMAT的查询会更快，尤其是数据量较大的时候。
• 如果需要统计的是分钟内平均并发而非峰值，可以把MAX(current_concurrent)换成AVG(current_concurrent)，不过通常业务场景更关注峰值。
• 这个方案的优势是逻辑透明：每个呼叫的开始和结束都对应一个明确的数值变化，累加过程完全模拟了并发数的实时变化，不会出现边界判断错误。

内容的提问来源于stack exchange，提问作者spaul