MySQL CPU持续100%告警分析：从慢查询堆积到连接风暴的排错实战

一、现象描述

监控系统告警频发，一个名为“财务共享”的生产环境 MySQL 实例出现了严重的性能问题，具体现象如下：

1. 数据库连接异常：应用系统告警，提示“[财务共享]系统[prod]数据库无法连接”。
2. 主机CPU资源耗尽：对应的主机（IP：172.1.0.1）监控显示，其CPU使用率已超过100%。
3. 数据库连接数激增：该 MySQL 实例的活跃连接数已达到596个，远超正常水平。

这三个现象相互关联，通常指向数据库实例自身出现了严重的性能瓶颈，导致处理能力下降，进而引发连接堆积。

二、分析过程

1. 操作系统层面确认进程负载

首先，我们需要在数据库服务器上确认是否是 mysqld 进程导致了高CPU使用率。通过 top 命令查看：

#top

命令输出显示，mysqld 进程的CPU占用率高达753%，这直接证实了数据库引擎是资源消耗的源头。

为了进一步定位是哪些数据库线程在“作怪”，我们使用 top -H -p <mysqld进程id> 来查看 mysqld 的所有子线程（即数据库连接线程）。观察发现，存在大量CPU占用在20%-30%左右的线程，虽然没有单个线程跑满100%，但数量庞大的线程累加导致了整体CPU的“爆表”。

2. 深入数据库内部：关联操作系统线程与MySQL会话

接下来，我们选取其中一个高占用的操作系统线程ID（例如613254），在 MySQL 内部查询其对应的数据库会话信息，以了解该线程正在执行什么操作。

SELECT a.THREAD_OS_ID,b.id,b.user,b.host,b.db,b.command,b.time,b.state,b.info
FROM performance_schema.threads a,information_schema.processlist b
WHERE b.id = a.processlist_id and a.THREAD_OS_ID=613254;

这条SQL通过关联 performance_schema.threads 和 information_schema.processlist 两个系统视图，可以精准定位到操作系统线程对应的 MySQL 连接及其正在执行的SQL语句。

3. 查看实时活跃会话全景

为了获得全局视图，我们直接查询当前所有非休眠状态的会话，并按执行时间降序排列，快速找出“慢查询”。

select * from information_schema.processlist where command != 'Sleep'  order by time desc limit 50;

查询结果触目惊心：大量复杂的 SELECT 嵌套查询正在并发执行，其中执行时间最长的已经达到了107秒。这些SQL正是消耗CPU资源的元凶。

根本原因分析：
结合以上排查，我们可以总结出导致此次CPU 100%告警的三个核心原因：

• 慢查询堆积：大量设计复杂、缺乏优化的嵌套查询长时间运行，持续消耗CPU计算资源。
• 连接风暴：高并发的应用请求撞上这些慢查询，导致请求处理不及时，连接数不断累积，形成恶性循环。
• 查询设计缺陷：SQL语句本身可能缺少必要的索引支持，或者写法上存在可优化的空间（如不必要的子查询、全表扫描等）。

三、处理措施

1. 紧急处理（止损）

当务之急是缓解数据库压力，恢复基本服务。通过终止执行时间最长的会话来快速释放资源。

生成终止（KILL）长时间运行会话的命令：

SELECT concat('KILL ', id, ';') AS kill_command
FROM information_schema.processlist
WHERE command != 'Sleep' AND time > 30
ORDER BY time DESC
LIMIT 50;

执行上述查询生成的 KILL 命令，可以批量杀掉执行超过30秒的会话。这是 一种临时性的止血措施，目的在于快速降低系统负载，为后续根因分析争取时间。

2. SQL优化与根治措施

止血之后，必须找到并解决根本问题，否则故障还会卷土重来。

(1) 识别TOP慢查询
从 MySQL 的慢查询日志中找出历史上最耗时的SQL语句，这些是重点优化对象。

SELECT * FROM mysql.slow_log
ORDER BY query_time DESC
LIMIT 20;

(2) 分析SQL执行计划
对找出的慢查询使用 EXPLAIN 命令进行分析，查看其执行计划，判断是否走了合适的索引，是否存在全表扫描、临时表、文件排序等耗性能的操作。

EXPLAIN 慢查询SQL;

(3) 为高频查询添加或优化索引
根据 EXPLAIN 的结果，针对 WHERE 条件、JOIN 关联字段、ORDER BY/GROUP BY 的列创建合适的组合索引。同时，也需要清理那些冗余或从未被使用到的索引，因为索引本身也会带来维护开销。
示例：

ALTER TABLE orders ADD INDEX idx_customer_status (customer_id, status);

(4) 重写复杂低效的查询
这是治本的关键。很多性能问题源于SQL写法本身。

• 避免在WHERE条件中对字段进行函数操作：例如 WHERE DATE(create_time) = ‘2024-04-10’ 会导致索引失效，应改为 WHERE create_time >= ‘2024-04-10’ AND create_time < ‘2024-04-11’。
• 简化嵌套查询：尝试将复杂的子查询改写为 JOIN 连接，有时使用临时表或公共表表达式（CTE）分步处理也能提升可读性和性能。
• **避免 SELECT ***：只查询需要的字段，减少网络传输和内存开销。
• 审视查询逻辑：检查是否存在可避免的重复计算或不必要的循环逻辑。

通过以上系统性的分析与优化，我们不仅解决了当次的 CPU 使用率100%告警，更重要的是建立了预防机制，提升了 MySQL 数据库的长期稳定性和性能。数据库运维的挑战往往在于快速定位与根治结合，更多关于 数据库性能调优 和 运维稳定性保障 的实战经验，欢迎在 云栈社区 与同行们交流探讨。