如何优化MySQL查询以高效实现每秒并发呼叫统计？

嘿，我之前做过类似的CDR并发呼叫统计需求，碰到过一模一样的慢查询问题，给你几个亲测有效的优化思路：

1. 给核心字段建立复合索引 #

并发统计的核心是快速筛选出某个时间点内正在活跃的呼叫（也就是start_time <= 统计秒数 AND end_time >= 统计秒数的记录），如果你的查询依赖呼叫开始时间、结束时间和呼叫类型，一定要建针对性的复合索引：

CREATE INDEX idx_call_time_type ON DB1.Data (start_time, end_time, call_type);

这个索引能让MySQL跳过全表扫描，直接定位到符合时间范围的目标数据，是提速最关键的一步。

2. 重构查询逻辑，避免逐秒遍历的低效写法 #

很多人一开始会用生成的每秒时间序列去关联主表逐秒统计，这种写法在时间范围大的时候会超级慢。推荐用事件点累计求和的思路：把每个呼叫的开始记为+1，结束的下一秒记为-1，然后按时间和呼叫类型累计计算并发数，示例代码如下（假设你的时间字段是call_start和call_end，类型为DATETIME）：

WITH time_events AS (
    -- 呼叫开始事件：并发数+1
    SELECT call_start AS event_time, call_type, 1 AS delta FROM DB1.Data
    UNION ALL
    -- 呼叫结束事件：下一秒并发数-1
    SELECT DATE_ADD(call_end, INTERVAL 1 SECOND) AS event_time, call_type, -1 AS delta FROM DB1.Data
),
sorted_events AS (
    -- 按时间和类型累计求和，得到每秒的并发数
    SELECT event_time, call_type, delta,
           SUM(delta) OVER (PARTITION BY call_type ORDER BY event_time) AS concurrent_calls
    FROM time_events
)
-- 最终输出每秒、每类呼叫的并发数
SELECT event_time AS stat_second, call_type, concurrent_calls
FROM sorted_events
ORDER BY stat_second, call_type;

这种写法不需要逐秒匹配所有呼叫，性能会比原来的方式提升几个量级。

3. 非实时场景：用预处理汇总表提速 #

如果你的统计不需要实时计算（比如每天生成历史报表），可以提前把统计结果预处理到一个汇总表：

• 定时（比如每天凌晨）跑上面的CTE查询，把当天的统计结果插入到CDR_Concurrent_Summary表
• 业务查询直接从汇总表读取，速度会快很多

示例预处理插入语句：

INSERT INTO CDR_Concurrent_Summary (stat_second, call_type, concurrent_count)
SELECT event_time, call_type, concurrent_calls
FROM sorted_events
WHERE event_time BETWEEN '2024-05-20 00:00:00' AND '2024-05-20 23:59:59';

4. 调整MySQL配置参数（针对大数据量场景） #

如果你的DB1.Data表数据量特别大，还要检查MySQL的内存配置：

• 把innodb_buffer_pool_size设为服务器内存的50%-70%（如果是专用数据库服务器），让MySQL尽可能把热点数据缓存到内存，减少磁盘IO

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