本文约 2,520 字，预计阅读 7 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：知道”慢”，但不知道”哪里慢”
站点打开要 3 秒，你会怎么做？装缓存插件、换主题、删插件——这些都是靠猜。
Query Monitor 的价值在于把猜测变成数据：它能告诉你这次请求执行了多少条 SQL、哪条最慢、是哪个插件发起的、有多少个 HTTP 请求、哪个钩子耗时最长。有了这些，优化才有方向。
原理分析：它凭什么能看到这些
Query Monitor 通过 WordPress 的钩子机制挂入几个关键位置：
wpdb的查询方法 → 记录每条 SQL 及其调用栈；SAVEQUERIES类似机制 → 记录耗时；all钩子 → 记录所有 action/filter 的执行时间；HTTP API的pre_http_request等 → 记录外部请求；shutdown时汇总输出到管理栏。
所以它带来一定开销，只建议在排查时启用，不要在流量高峰长期开着（尤其是后台）。
保姆级实操
第一步：安装与基本使用
wp plugin install query-monitor --activate
启用后，登录后顶部管理栏会显示一组数据：页面生成时间、内存峰值、数据库查询数、查询耗时。点击展开面板。
第二步：七个面板分别看什么
1. Overview（总览）
- Page generation time：PHP 生成页面耗时；
- Peak memory usage：内存峰值；
- Database query time：数据库总耗时。
如果”数据库查询时间”占比很高 → 优化数据库；如果生成时间长但查询少 → 是 PHP 逻辑或外部请求慢。
2. Database Queries（数据库查询） —— 最常用
可切换排序方式：
- Queries by Component：按插件/主题/核心分组，直接看出哪个插件查得最多；
- Queries by Time：按耗时排序，找出最慢的 SQL；
- Slow Queries：超过阈值的查询；
- Duplicate Queries：重复执行的相同查询（典型的优化点）。
点击单条查询能看到 Caller（调用栈），直接定位到是哪个文件的哪一行。
常见慢查询模式：
| 模式 | 含义 | 优化 |
|---|---|---|
SELECT * FROM wp_postmeta WHERE post_id = X 大量重复 |
N+1 查询 | 用 update_meta_cache 或改用批量查询 |
SELECT ... FROM wp_posts WHERE 1=1 ORDER BY RAND() |
随机排序全表扫描 | 改用缓存或固定推荐位 |
SELECT ... LIKE '%关键词%' |
全表扫描 | 加索引或换搜索方案 |
| 上千条查询 | 插件过多或某插件设计差 | 按 Component 定位后替换插件 |
3. Hooks & Actions（钩子）
列出所有 action/filter 及各自耗时。重点看：
- 耗时异常长的钩子（> 100ms）；
- 同一个钩子下挂了大量回调。
4. HTTP API Requests（外部请求）
列出页面加载期间发起的所有外部 HTTP 请求及耗时。这里经常能发现：
- 主题在请求 Google Fonts（国内慢）；
- 插件在请求远程 API（天气、汇率、社交计数）；
- 更新检查请求。
每一个外部请求都可能是几百毫秒。
5. Conditionals（条件判断）
显示当前请求是 is_home()、is_single() 等。用于确认模板匹配是否符合预期。
6. PHP Errors
显示 notices、warnings、deprecated 提示。很多插件在 PHP 8.x 下会报 deprecated，虽然不致命，但数量多会拖慢执行。
7. Scripts & Styles
列出所有注册的 CSS/JS、句柄、依赖、位置。用于发现：
- 加载了但本页用不到的资源；
- 重复加载的 jQuery；
- 应该放页脚却在头部的脚本。
8. Rewrite Rules
显示当前匹配的重写规则。排查 404 和路由问题很有用。
第三步：只对自己启用（降低影响）
在 wp-config.php 里设 Cookie，让 Query Monitor 只对特定用户生效：
define('QM_ENABLE', false); // 默认关闭
然后在浏览器控制台执行（需要插件支持）或用插件设置里的 “Authentication cookie”。
更简单的做法：不排查时就停用插件。
第四步：结合慢日志
Query Monitor 看单页，慢日志看全局。两者配合：
; www.conf
slowlog = /var/log/php8.2-fpm/slow.log
request_slowlog_timeout = 3s
常见踩坑与失败案例
- 后台变卡 —— Query Monitor 本身有开销，尤其数据库查询上千的站点。排查完记得停用。
- 看不到数据 —— 需要登录状态且管理栏可见；前台未登录时默认不输出。
- 案例：某站首页 1800 条查询，按 Component 分组发现某”相关文章”插件贡献了 1200 条。换成基于标签的静态推荐后降到 90 条，首页 TTFB 从 2.1s 降到 380ms。
- Duplicate Queries 大量出现 —— 通常是主题在循环里反复调用
get_post_meta()。改为在循环外一次性get_post_custom()或用缓存。 - 误判 PHP 错误 —— deprecated 提示不等于故障，但 PHP 9 之后可能变成错误，建议逐步清理。
总结
Query Monitor 最实用的三个面板是数据库查询（按组件分组）、HTTP 请求、钩子耗时。标准排查流程：先看总览判断瓶颈在数据库还是 PHP → 按组件分组找出贡献最大的插件 → 看 HTTP 请求有没有外部依赖 → 用调用栈定位具体代码行。整个过程十分钟内能完成，比”删插件试试”高效得多，也更有说服力。
