线上MySQL数据库CPU占有率飙升，通常意味着数据库正在经历某种形式的性能瓶颈，核心问题往往围绕着“谁在消耗CPU”和“为什么会消耗这么多”。排查思路的核心在于由表及里，从系统层面观察到数据库内部，最终定位到具体的查询、配置或系统资源问题。这就像医生看病，先看症状，再做检查，最后对症下药。
解决线上MySQL CPU飙升的问题，需要一套系统性的排查流程，这不仅仅是看几个参数那么简单，更是一种思维模式。我的经验是，当你看到CPU曲线冲上云霄时，首先要做的不是慌张，而是冷静地收集现场信息，这包括操作系统层面的资源使用情况，以及MySQL内部正在发生什么。
为什么我的MySQL CPU突然飙高，最常见的原因是什么？说实话，MySQL CPU突然飙高，原因五花八门，但最常见的，往往脱不开那几个“老面孔”。在我看来，这就像一个顽固的病症，总有那么几类病因反复出现。
最首当其冲的，绝对是未优化的复杂查询。你想想看，一个原本设计就不太合理的SQL，比如一个大表全表扫描，或者一个多表关联（JOIN）没有走对索引，它在数据量小的时候可能没什么感觉，一旦数据量上来，或者并发一高，那可就是实实在在的CPU杀手。特别是那些涉及大量排序（
ORDER BY）、分组（
GROUP BY）或者使用了
DISTINCT、
UNION等操作的查询，如果缺乏合适的索引，MySQL就不得不把大量数据加载到内存甚至磁盘上进行计算，这期间CPU的消耗是巨大的。我见过不少案例，一个看似简单的报表查询，因为缺少一个复合索引，直接把CPU打满。
其次，高并发短连接也是个隐形杀手。虽然单个连接的开销不大，但如果你的应用层没有正确使用连接池，或者连接池配置不当，导致MySQL需要频繁地建立和销毁连接，那么光是这些连接管理的开销，就足以让CPU不堪重负。每个新连接的建立、认证、以及后续的线程上下文切换，都是CPU的负担。
再来，大量的写入操作也不容忽视。特别是当你的表有大量索引时，每一次写入（INSERT、UPDATE、DELETE）都需要更新相关的索引，这本身就是CPU密集型的工作。如果写入并发很高，或者事务很大，还会涉及到锁竞争、日志刷盘等操作，这些都会进一步推高CPU。
还有一种情况，常常被我们忽略，那就是统计信息过时。MySQL的查询优化器是基于统计信息来选择执行计划的。如果统计信息不准确，优化器可能会选择一个次优的执行计划，导致查询效率低下，进而消耗更多CPU。这就像一个导航系统，如果地图数据过时了，它可能会给你规划一条拥堵不堪的路线。
最后，操作系统层面的资源瓶颈有时也会伪装成MySQL CPU高。比如内存不足导致大量SWAP，CPU可能大部分时间都在等待I/O，而不是真正地执行计算。或者磁盘I/O成为瓶颈，MySQL线程在等待磁盘读写时，虽然
mysqld进程的CPU使用率高，但实际上它是在“忙等”。所以，排查时不能只盯着MySQL内部，也要看看整个系统的健康状况。 如何通过MySQL自带工具快速定位问题查询？
当CPU告警响起，我的第一反应通常是“谁在跑，跑了多久，在做什么？”。这时候，MySQL自带的那些工具，就像是你的X光片和CT，能帮你快速锁定嫌疑犯。
最直接、最粗暴但往往最有效的，就是
SHOW FULL PROCESSLIST命令。这个命令能列出所有正在运行的线程，包括它们的ID、用户、主机、数据库、命令、运行时间、状态以及最重要的——
Info字段，也就是正在执行的SQL语句。
SHOW FULL PROCESSLIST;
你得关注那些
Time字段值很大（比如几十秒甚至几百秒）的查询，它们可能是长事务或者慢查询。更要留意
State字段，一些关键状态如
Sending data,
Sorting result,
Copying to tmp table,
Locked等，都预示着查询可能正在进行大量计算或等待资源。比如
Sending data通常意味着MySQL正在处理结果集并发送给客户端，这期间可能涉及大量的数据读取和网络传输；
Sorting result和
Copying to tmp table则明确指出查询正在进行内存或磁盘上的排序或临时表操作，这都是CPU消耗大户。
如果
SHOW FULL PROCESSLIST不能即时捕获到那些“一闪而过”但频率极高的短查询，那么慢查询日志（Slow Query Log）就派上用场了。你需要确保它已经开启，并且
long_query_time设置得合理（比如1秒）。
# my.cnf 或 my.ini 配置 slow_query_log = 1 slow_query_log_file = /var/log/mysql/mysql-slow.log long_query_time = 1 log_queries_not_using_indexes = 1 # 推荐开启，能捕获未走索引的查询
慢查询日志会记录所有执行时间超过
long_query_time阈值的查询。仅仅开启还不够，你需要定期分析它。
mysqldumpslow是一个简单的官方工具，但如果想更深入地分析，我更推荐使用Percona Toolkit里的
pt-query-digest。它能对慢查询日志进行聚合分析，告诉你哪些查询出现的频率最高、总耗时最长、平均耗时如何，以及它们的执行计划摘要。这对于发现那些“积少成多”的CPU消耗型查询特别有效。
PIA
全面的AI聚合平台，一站式访问所有顶级AI模型
226
查看详情
对于更高级、更细粒度的监控，Performance Schema和基于它的Sys Schema是你的利器。Performance Schema提供了大量的事件监控，可以追踪到语句、阶段、文件I/O等各个层面的性能数据。虽然直接查询Performance Schema的表有点复杂，但Sys Schema将其封装得非常友好。
比如，你可以通过Sys Schema快速查看哪些查询消耗了最多的总执行时间：
SELECT
digest_text,
count_star,
sum_timer_wait / 1000000000000 AS total_seconds,
avg_timer_wait / 1000000000000 AS avg_seconds
FROM
sys.statements_with_errors_or_warnings
ORDER BY
sum_timer_wait DESC
LIMIT 10; 或者查看哪些查询导致了全表扫描：
SELECT
db,
query,
full_scan,
exec_count,
total_latency
FROM
sys.statements_with_full_table_scans
ORDER BY
total_latency DESC
LIMIT 10; 一旦定位到具体的嫌疑查询，下一步就是使用
EXPLAIN命令来分析其执行计划。
EXPLAIN SELECT * FROM your_table WHERE your_column = 'value';
EXPLAIN的输出是理解查询性能的关键。重点关注
type（访问类型，
ALL代表全表扫描，
index代表全索引扫描，
ref或
eq_ref是好的，
const最好）、
rows（预计扫描行数）、
Extra字段。如果
Extra中出现
Using filesort或
Using temporary，那几乎可以肯定这是一个CPU消耗大户，意味着MySQL需要额外进行文件排序或创建临时表来完成查询。这些都是优化索引的直接信号。 除了查询优化，还有哪些系统或配置层面的因素需要考虑？
当然，CPU飙高并非总是SQL的锅，有时，问题可能出在更底层，比如系统资源本身不足，或者MySQL的配置参数没有调优到最佳状态。这就像一辆车，光是引擎好不够，油箱、变速箱、轮胎都得配合得当。
首先，硬件资源瓶颈是绕不开的话题。即使你的SQL写得再漂亮，如果服务器的CPU核心数不够，或者主频太低，面对高并发时依然会力不从心。内存也是一个关键因素，如果
innodb_buffer_pool_size设置得太小，导致热数据无法完全缓存，MySQL就不得不频繁地从磁盘读取数据，这会把I/O压力转嫁到CPU上，因为CPU在等待I/O完成。我遇到过不少情况，看起来CPU很高，但实际上是
iowait时间占了大头。同样的，磁盘I/O性能不足，也会让CPU在等待数据读写时空转。用
top、
vmstat、
iostat这些命令，可以帮你全面了解CPU、内存、磁盘和网络的整体使用情况。
其次，MySQL配置参数的合理性至关重要。
my.cnf里的每一个参数都可能影响性能。
-
innodb_buffer_pool_size
: 这是InnoDB最重要的参数，它决定了InnoDB可以缓存多少数据和索引。通常建议设置为物理内存的50%-70%。如果设置太小，会导致大量物理I/O，间接增加CPU开销。 -
max_connections
: 连接数过高会显著增加MySQL的CPU开销，因为每个连接都需要维护一个线程，涉及到上下文切换和资源分配。设置一个合理的值，并确保应用层有正确的连接池管理。 -
tmp_table_size
和max_heap_table_size
: 这两个参数决定了内存临时表的大小。如果查询需要创建临时表，并且结果集超过这个大小，MySQL就会在磁盘上创建临时表，导致大量的磁盘I/O和CPU消耗。适当增大它们，有助于将临时表留在内存中。 -
thread_cache_size
: 线程缓存大小，用于缓存空闲的客户端线程。如果这个值设置得太小，MySQL就需要频繁地创建和销毁线程，这会消耗CPU。 -
sync_binlog
和innodb_flush_log_at_trx_commit
: 这两个参数关系到数据安全性和写入性能的权衡。极端情况下，为了保证数据不丢失，它们可能会设置为1，这意味着每次事务提交都会强制刷盘，导致大量的I/O操作，进而影响CPU。在可以接受一定数据丢失风险（比如主从复制可以弥补）的情况下，可以适当调整，但要非常谨慎。 -
query_cache_size
: 现代MySQL版本中，查询缓存的效率并不高，甚至可能导致性能下降和CPU竞争。通常建议禁用（设置为0）或保持很小。
再者，操作系统层面的配置有时也会成为瓶颈。例如，文件句柄限制（
ulimit -n）如果太低，可能导致MySQL无法打开足够的表文件或日志文件。SWAP空间过度使用是另一个明显的信号，它表明系统内存不足，导致CPU大部分时间在进行页面置换。此外，Linux的I/O调度器选择（如
deadline、
noop通常优于
cfq）也会影响磁盘I/O性能。透明大页（Transparent Huge Pages, THP）在某些场景下也可能导致MySQL性能下降，建议禁用。
最后，应用层的行为也可能间接导致MySQL CPU飙高。比如，应用程序是否有效使用了连接池？是否有大量短时间内爆发的批处理操作？事务管理是否合理，是否存在长时间未提交的大事务？N+1查询问题（即在一个循环中执行N次查询）也是常见的应用层性能陷阱，它会导致大量的数据库往返和查询执行，从而推高CPU。这些问题需要和开发团队紧密协作才能发现和解决。
总而言之，排查MySQL CPU飙高是一个系统工程，需要你从宏观到微观，从系统到应用，层层深入，抽丝剥茧。没有一劳永逸的解决方案，只有不断地分析、优化和迭代。
以上就是线上MySQL数据库CPU占有率飙升问题的排查思路的详细内容，更多请关注知识资源分享宝库其它相关文章！
相关标签： mysql linux 操作系统 工具 ssl ai ios sql语句 数据丢失 为什么 sql mysql 封装 const union 循环 using 线程 delete 并发 事件 table 数据库 linux 大家都在看： MySQL内存使用过高（OOM）的诊断与优化配置 MySQL与NoSQL的融合：探索MySQL Document Store的应用 如何通过canal等工具实现MySQL到其他数据源的实时同步？ 使用Debezium进行MySQL变更数据捕获（CDC）实战 如何设计和优化MySQL中的大表分页查询方案
发表评论:
◎欢迎参与讨论，请在这里发表您的看法、交流您的观点。