第4期 MySQL数据库CPU利用率过高

来源：这里教程网时间：2026-03-01 18:24:48 作者：

现象描述

数据库 MySQL 出现响应变慢、无法获取连接、超时等现象。当数据库 MySQL CPU 利用率超过80%时，可能会出现业务响应变慢、超时、无法连接数据库等现象。

数据库 MySQL CPU 使用情况，可在 liunx命令top查看。

说明

CPU 利用率过高时，如果使用的是云主机或者云服务建议优先开启 CPU 弹性扩容，支持手动/自动扩展 CPU，可轻松应对突发压力，保障线上业务稳定性，若 CPU 和内存都需要扩容时，建议进行配置调整，提升实例规格以确保业务正常运行，后续可参考本文进行排查和优化。

故障风险

若 MySQL CPU 的利用率长时间处于过高状态，会严重影响数据库的整体性能，极端情况下可能会出现实例 HANG 住的情况。

当使用HA时，HA探测到实例 HANG 后，为了保证用户业务的高可用性，会触发主备切换，在主备切换的过程中，业务会出现短时间的不可用，实例不可用的时长正常情况下不超过60秒。如在业务高峰期发生了主备切换，会严重影响业务的稳定和连续性。

为避免业务因 CPU 资源不足而受影响，建议提前对 CPU 利用率过高的实例进行业务优化或者升级 CPU 资源。实例发生主备切换时会出现秒级的闪断，对于长连接需要应用具备重连的机制。

可能原因

MySQL 主要是两类线程占用 CPU：系统线程和用户线程。因此 MySQL 独占的服务器上，仅需关注这两类线程的情况，就能解决大部分的故障场景。

用户线程

用户线程繁忙，大部分场景都是由“慢查询”引起的，除“慢查询”因素外，还有“计算量大”和“高 QPS”因素。

慢查询进行长时间的计算，例如：order by，group by，临时表，join 等。这一类问题是查询效率不高，导致单个 SQL 语句长时间占用 CPU 时间。

计算量大单纯的数据量比较多，导致计算量巨大。

高 QPS（Queries Per Second ）单纯的 QPS 压力高，所以 CPU 的时间被用满了，如：4 核的服务器用来支撑 20k 到 30k 的点查询，每个 SQL 占用的 CPU 时间并不多，但是因为整体的 QPS 很高，所以 CPU 的时间被占满了。

系统线程

在实际的环境中，系统线程遇到问题的情况会比较少，一般来说，多个系统线程很少会同时跑满，只要服务器的可用核心数大于等于 4 ，一般也不会遇到 CPU 利用率过高，当然有一些 bug 可能会有影响，如下图所示：

解决思路

大部分故障场景，基本是用户线程繁忙导致，因此本文主要介绍用户线程导致的 CPU 利用率过高问题，提供对应的解决方案。

慢查询：建议开启慢查询sql日志，通过慢查询sql日志来排查和优化。

计算量大：因处理数据量大，导致 CPU 利用率过高，即使索引和执行计划没什么问题，也会导致 CPU 利用率过高。

一般来讲，这类问题有如下两种比较常规的解决方案：读写分离，把这一类查询放到平时业务不怎么用的只读从库去。

在程序段拆分 SQL，把单个大查询拆分成多个小查询。

高 QPS：因访问量过大，导致 CPU 利用率过高，挂载只读实例，分担主实例压力。优化查询语句，提升执行效率。

处理步骤

慢查询

建议开启慢查询sql日志，通过慢查询sql日志来排查和优化。MySQL 慢查询时间（long_query_time）的默认值是1s，在遇到性能问题时，若发现没有慢查询，建议将参数值调小，再观察业务周期内的慢查询，进而对其慢查询进行优化。若参数调整后，在其业务周期内依然未发现慢查询，而 CPU 利用率依然偏高，建议升级 CPU 的配置，进而提高数据库的整体性能。