WordPress 变慢？先查 MySQL 慢查询

我是小够，只推够用的 VPS。

WordPress 变慢，很多人第一反应是"升级 VPS 配置"。先打住——多数慢，是数据库的锅，不是配置的锅。今天讲慢查询排查，揪出拖后腿的 SQL 再说。升级配置是最后手段，不是第一反应。

第一步：开慢查询日志

MySQL/MariaDB 都能记录"执行超过 N 秒"的 SQL。进数据库执行：

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 2;

long_query_time = 2 表示记录超过 2 秒的查询。日志文件一般在数据目录下（文件名类似 slow.log）。开一天，收集够样本再分析——别开着就不管，日志会越写越大。查完记得关掉，或者配置日志轮转，定期归档删除。

想永久生效，把配置写进 my.cnf 的 [mysqld] 段，重启生效。临时排查用上面的 SET GLOBAL 就够了，重启数据库后自动恢复默认——临时开、及时关，别留尾巴。

第二步：看是谁在拖后腿

打开慢日志，重点看三类：

1. 全表扫描。拿可疑的 SQL 去 EXPLAIN 一下，type=ALL 且 rows 很大——这是缺索引的典型症状。数据库把整张表翻一遍才找到几行数据，能不慢吗？

2. 某个插件的查询反复出现。比如统计插件、相关文章插件，每次页面加载都跑几十条重查询——插件作妖实锤。WordPress 生态里这类"功能很香、查询很重"的插件不少， Related Posts、某些统计插件都是重灾区。

3. 定时任务堆积。WordPress 的 wp-cron 里塞了太多定时任务，每次访问都触发一堆后台任务。表现是"首页偶尔卡一下"，日志里一堆定时任务的查询。

第三步：对症下药

缺索引：给 WHERE/JOIN 里的字段加索引。WordPress 表结构是标准的，网上有现成的优化 SQL 参考。操作前备份数据库——动索引是动表结构，备份是铁律。加完索引用 EXPLAIN 再验证一遍，type 从 ALL 变成 ref/range 就对了。

插件作妖：关掉或换掉那个插件。统计类插件是重灾区——换成服务端统计（如自己搭的轻量统计）或精简版，效果立竿见影。判断标准：停用插件后慢查询日志立刻干净，那就是它。

wp-cron 太重：禁用页面触发式 cron，在 wp-config.php 加：

define('DISABLE_WP_CRON', true);

改用系统 cron 每 5 分钟跑一次 wp-cron.php，访问和定时任务解耦——访客打开页面不再被定时任务拖慢，定时任务也有了固定节奏。

进阶：对象缓存是最好的"止痛药"

MySQL 自身的查询缓存（8.0 已移除，别找了）指望不上，正确姿势是对象缓存（Redis）：把高频查询结果放内存，数据库压力骤降。慢查询优化是"治本"（修坏 SQL），对象缓存是"止痛"（少查数据库）——两个一起上，1 核 2G 跑流畅 WordPress 是标配组合。

但记住顺序：先治本，再止痛。一个全表扫描的坏 SQL，套上缓存只是"慢得少一点"，根子还在。先修 SQL，再上缓存。

慢查询之外的慢：连接数和锁

慢日志干净，但网站还是慢？看两个地方：

1. 连接数打满。MySQL 默认最大连接数 151，WordPress 每个 PHP 进程都要连数据库，并发一高就排队。用 SHOW STATUS LIKE 'Threads_connected'; 看当前连接数，长期接近上限就调大 max_connections——但先确认是真不够，而不是有慢查询占着连接不放。治标之前先治本。

2. 表锁/行锁等待。MyISAM 引擎是表锁，一写全表等；InnoDB 是行锁，粒度细得多。2025 年了，所有表都应该是 InnoDB，检查一下有没有漏网的 MyISAM 表，有就转了：

ALTER TABLE 表名 ENGINE=InnoDB;

转之前备份，这是动表结构的操作。

小够总结

排查慢站的顺序：开慢查询日志 → 揪出坏 SQL → 索引/插件/定时任务三选一修 → 上 Redis 对象缓存。走完这套还慢，再考虑升级配置——小够敢说，八成网站到第二步就解决了。记住这个排查顺序，下次网站变慢，你就知道先看哪，而不是先打开商家后台看涨价。