答案：MySQL CPU飙升常见原因为慢查询、高并发连接、大量写入、统计信息过时及系统资源瓶颈。需通过SHOW PROCESSLIST、慢查询日志、Performance Schema等工具定位问题SQL，结合EXPLAIN分析执行计划，并检查innodb_buffer_pool_size、max_connections等配置，同时关注系统I/O、内存、连接池及应用层设计，综合排查优化。
线上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消耗型查询特别有效。
对于更高级、更细粒度的监控，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飙高是一个系统工程，需要你从宏观到微观，从系统到应用，层层深入，抽丝剥茧。没有一劳永逸的解决方案，只有不断地分析、优化和迭代。
