MySQL 查询速度突然变慢怎么办？建立一套系统化排查方法

MySQL查询速度突然变慢怎么办 从执行计划到系统资源建立完整排查方法

MySQL查询原本运行正常，某一天突然从几十毫秒变成几秒，甚至几十秒，这类问题最容易让开发人员误以为“索引失效了”。实际上，查询突然变慢往往不是单一原因造成的，执行计划变化、数据量增长、统计信息失真、锁竞争、Metadata Lock、磁盘I/O、内存压力、连接数暴涨以及应用层并发变化，都可能让一条原本正常的SQL突然出现性能下降。

因此，处理这类故障不能一上来就修改索引或调整MySQL参数。专业排查的核心，是先找出“发生了什么变化”，再判断变化是否与性能下降存在因果关系。

先确认到底是哪一类查询变慢

首先需要确认问题是真正发生在MySQL执行阶段，还是应用程序、网络、连接池或者结果集处理阶段。

如果应用访问接口从原来的200毫秒变成5秒，但数据库中的SQL实际只执行100毫秒，那么继续优化SQL没有意义。应该检查连接建立、连接池等待、网络传输以及应用程序处理时间。

如果数据库本身执行时间明显增加，则进一步确认是单条SQL变慢，还是大量SQL同时变慢。

可以先执行：

SHOW FULL PROCESSLIST;

观察当前线程状态、执行时间以及等待原因。

对于正在运行的SQL，可以重点关注：

Waiting for table metadata lock
Waiting for ... lock
Waiting for disk
Sending data
Creating sort index
Creating tmp table

其中，Waiting for table metadata lock尤其值得注意。某个事务长时间持有Metadata Lock时，即使查询本身只有几毫秒，也可能让其他SQL全部排队。

先用EXPLAIN确认执行计划有没有变化

对于突然变慢的SQL，第一件重要的事情通常是保存当前执行计划。

例如：

EXPLAIN
SELECT *
FROM users
WHERE name = 'test'
AND age > 20;

重点检查possible_keys、key、key_len、rows、filtered以及Extra。

如果原来使用了某个索引，现在突然变成：

key = NULL
type = ALL

就需要继续调查为什么优化器改变了选择。

但不能看到type = ALL就认定一定存在问题。如果表只有几百行，全表扫描可能比索引访问更加高效。同样，type = index代表全索引扫描，也不能简单理解为“使用了索引所以性能很好”。

MySQL 8.x环境还可以使用：

EXPLAIN ANALYZE
SELECT *
FROM users
WHERE name = 'test'
AND age > 20;

普通EXPLAIN主要提供优化器的估算信息，而EXPLAIN ANALYZE能够结合实际执行过程观察实际耗时和实际扫描情况。对于“估算和现实严重不一致”的SQL，这一点尤其重要。

检查统计信息和数据分布

如果SQL没有修改，索引也没有删除，但执行计划突然改变，就需要考虑统计信息和数据分布。

优化器并不是简单地“看到索引就使用”，它会根据估算成本选择执行计划。如果某个字段以前具有很高的选择性，后来大量数据拥有相同的值，原来的索引可能就不再具有同样的成本优势。

例如：

SELECT *
FROM orders
WHERE status = 'pending';

假设以前只有1%的订单处于pending状态，索引非常有价值。后来由于业务故障，80%的订单都变成pending，优化器可能认为扫描大量索引记录再回表的成本已经很高。

因此，突然变慢时需要检查数据量、数据分布和统计信息，而不是机械地重新建立索引。

慢查询日志比猜测更加可靠

生产环境应该建立慢查询监控，而不是等用户投诉之后才开始寻找SQL。

典型配置可以根据业务情况设置：

slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1

long_query_time并不存在一个适合所有系统的固定值。高性能系统可能需要关注几十毫秒或几百毫秒级查询，而普通业务系统可以从1秒左右开始。

分析慢查询时，重点不是单纯寻找“最慢的一条”，而是观察：

Query_time
Lock_time
Rows_sent
Rows_examined

如果一条SQL只返回10行，却扫描了500万行，那么真正需要解决的是扫描量。

例如：

Rows_sent: 10
Rows_examined: 5,000,000

这种比例通常比单纯看到“执行了2秒”更有诊断价值。

检查锁竞争和长事务

如果SQL本身没有明显问题，却突然大量等待，锁竞争可能是根源。

InnoDB环境可以查看：

SHOW ENGINE INNODB STATUS\G

同时结合当前事务和锁等待信息进行分析。

MySQL 8.x还可以查看Performance Schema中的相关锁等待信息。

特别需要注意长事务。一个事务打开后长时间不提交，可能持有锁、阻止其他事务继续执行，甚至造成大量连接堆积。

因此发现数据库突然变慢时，需要回答一个问题：

到底是SQL执行时间增加了，还是SQL在等待其他事务？

两者解决方法完全不同。

Metadata Lock同样可能制造“全站变慢”

生产环境中一个非常容易被忽略的问题是Metadata Lock。

例如某个事务正在访问一张表，此时另一个连接执行：

ALTER TABLE users ...

DDL操作可能需要Metadata Lock。如果前面的事务迟迟没有结束，DDL就可能等待；而后续访问同一张表的SQL也可能继续排队。

最终表现出来的现象可能是：

一个ALTER TABLE
↓
Metadata Lock等待
↓
大量SQL排队
↓
应用接口大量超时
↓
看起来像“MySQL突然变慢”

因此遇到数据库整体突然卡顿时，不能只盯着慢查询日志，也必须检查锁等待和Metadata Lock。

检查CPU、内存和磁盘I/O

SQL没有变化、执行计划也没有明显变化，并不代表数据库没有问题。

Linux服务器上可以同时观察：

top
htop
free -m
iostat -xz 1
vmstat 1

如果CPU突然接近满载，需要确认究竟是MySQL线程、其他服务还是系统进程占用了CPU。

如果内存不足并开始发生swap，数据库性能可能出现明显下降。

如果磁盘I/O等待突然升高，则需要检查：

磁盘吞吐量
IOPS
await
util
随机读写
redo log写入
临时文件

尤其是InnoDB，当工作集无法有效留在Buffer Pool中时，磁盘读取增加会直接影响查询延迟。

Buffer Pool不能简单套用固定百分比

innodb_buffer_pool_size非常重要，但不能机械规定“设置成物理内存的70%到80%”。

如果服务器是一台专用数据库服务器，这种比例可以作为初步经验参考；如果MySQL同时与PHP、Node.js、Redis、Web服务器或者其他服务运行在同一台机器上，则必须为其他进程、连接缓冲区、临时表和操作系统预留足够内存。

调整前应该先观察实际内存压力，而不是直接修改参数。

索引优化必须建立在真实SQL上

索引设计应该围绕真实查询模式，而不是按照“每个字段都建立索引”的思路进行。

例如：

INDEX(tenant_id, status, created_at)

是否合理，需要结合实际的WHERE、JOIN、ORDER BY、GROUP BY以及数据分布判断。

复合索引需要考虑最左前缀原则，但字段顺序也不能简单按照“使用频率最高的字段排第一”。

同时应该检查重复索引和冗余索引。索引并不是越多越好，因为每增加一个索引，都意味着INSERT、UPDATE、DELETE时需要维护更多索引结构，并增加磁盘空间和Buffer Pool压力。

覆盖索引在合适的查询中能够减少回表，但也不能为了覆盖一个查询而无限增加索引字段。

不要把分区表当成“大表万能药

一张表超过100万行，并不意味着必须分区。

分区真正有价值的场景通常与查询条件、分区裁剪以及数据生命周期管理有关。

例如按照日期进行RANGE分区，在需要快速清理历史数据的业务中可能非常有用：

PARTITION BY RANGE (YEAR(created_at))

但如果查询条件无法有效利用分区裁剪，分区反而可能增加管理复杂度。

因此，决定是否分区之前，应该先分析实际SQL和数据生命周期，而不是根据行数机械决定。

不要随意执行OPTIMIZE TABLE

OPTIMIZE TABLE不是解决所有“MySQL变慢”问题的万能命令。

对于InnoDB，执行相关操作可能涉及表重建、I/O以及Metadata Lock等影响。生产环境使用之前，需要确认MySQL版本、存储引擎、表大小以及业务窗口。

如果只是因为查询变慢就执行：

OPTIMIZE TABLE table_name;

很可能没有解决真正的问题。

MySQL版本也会影响排查方法

如果服务器使用MySQL 8.x，就不要直接照搬很多针对MySQL 5.7甚至更早版本的资料。

例如MySQL 8.0已经移除了Query Cache，因此过去常见的：

Waiting for query cache lock

不应该再作为MySQL 8.0环境的常规排查项目。

事务隔离级别也应该使用当前版本对应的变量进行检查：

SELECT @@transaction_isolation;

至于使用REPEATABLE READ还是其他隔离级别，应根据业务的一致性要求和并发模型决定，而不是把某个隔离级别当成解决查询变慢的固定方案。

真正有效的排查顺序

遇到“以前很快，现在突然很慢”，可以按照下面的顺序建立故障路径：

应用响应时间
↓
确认数据库实际执行时间
↓
定位具体慢SQL
↓
EXPLAIN / EXPLAIN ANALYZE
↓
检查执行计划是否变化
↓
检查Rows_examined和实际返回行数
↓
检查统计信息和数据分布
↓
检查锁等待和长事务
↓
检查Metadata Lock
↓
检查CPU、内存、Swap、磁盘I/O
↓
检查Buffer Pool、临时表和连接数
↓
最后再考虑索引和配置调整

这个顺序的意义在于，尽可能先寻找证据，而不是先修改系统。

MySQL突然变慢，很少是“数据库自己突然坏了”。更常见的情况是某个变量发生了变化：数据量增加了，数据分布改变了，执行计划变了，某个事务没有提交，DDL产生了Metadata Lock，磁盘开始出现I/O瓶颈，应用并发突然增加，或者服务器内存已经无法维持原来的工作集。

因此，真正专业的数据库优化并不是不断增加索引、扩大内存或者修改几个参数，而是建立一条能够从SQL → 执行计划 → 锁 → I/O → 内存 → 系统资源 → 应用行为逐层验证的证据链。

当查询速度突然下降时，先找变化，再找原因，最后才是优化。这样处理，才能避免把一个锁等待问题误诊成索引问题，也能避免为了几条慢SQL修改整个生产数据库的配置。