2026.09.10

Query Monitor：找出 WordPress 後台變慢的外掛與資料庫查詢

WordPress 後台變慢時，常見症狀是控制台轉圈很久、文章編輯器開啟緩慢、儲存文章卡住，或只有某個管理頁面特別慢。這不一定代表主機整體效能不足，也可能是某個外掛執行大量資料庫查詢、等待外部 HTTP API，或佈景主題在後台載入不必要的程式。Query Monitor 是實際排查這類問題的工具，可以把一次請求花費的時間、資料庫查詢與來源元件列出來。

一、先記錄變慢的實際情境

先用管理員帳號開啟無痕視窗，記錄哪一個後台網址變慢，例如「文章列表」、「編輯文章」或 WooCommerce 訂單頁。不要只測試控制台首頁，因為不同頁面會觸發不同外掛。也記下大約載入時間、發生時間，以及是否只有特定帳號或特定內容會出現問題。

二、安裝並開啟 Query Monitor

到「外掛」→「安裝外掛」，搜尋 Query Monitor，確認作者為 John Blackbourn 後安裝並啟用。啟用後，登入管理員通常會在上方工具列看到 Query Monitor 的摘要數字；點擊後可開啟詳細面板。建議先重新載入剛才變慢的後台頁面，再查看這一次請求的資料。

三、先看總覽，再定位慢查詢

Queries／Database Queries：查看查詢總數、總耗時與重複查詢。可依查詢時間排序，優先檢查花費時間最高的項目。
Queries by Component：依 WordPress 核心、外掛、佈景主題分類。若某個外掛占用大部分查詢時間，便是重要線索。
Query Types：觀察 SELECT、INSERT、UPDATE 等類型。大量 SELECT 可能是列表或篩選功能，反覆 UPDATE 則可能是設定或紀錄程式在每次載入時執行。
Duplicate Queries：同一查詢被重複執行時，先確認是否真的造成明顯耗時，不要只因數量多就直接判定為錯誤。

點開單筆查詢後，查看 SQL、耗時與呼叫位置。若畫面提供 Caller 或呼叫堆疊，通常能看到外掛檔案、函式名稱或佈景主題路徑。這比只看 SQL 文字更重要，因為相似的查詢可能由不同元件產生。

四、檢查 HTTP API 與外部等待

若資料庫查詢並不慢，請切換到 HTTP API Calls。這裡會列出外掛或佈景主題呼叫的外部網址、回應時間、狀態碼與錯誤。看到某個請求等待數秒、回傳 403、429 或逾時，通常表示外部服務、授權、DNS 或防火牆造成延遲，不代表資料庫本身有問題。

五、用停用測試確認來源

先在測試站或維護時段操作，記錄目前啟用的外掛與版本。針對 Query Monitor 指出的可疑外掛，先停用一個，再重新載入同一個後台頁面，比較查詢數、總耗時與 HTTP API 時間。若速度明顯改善，再重新啟用該外掛，確認問題是否重現；接著才測試下一個元件。

若停用外掛沒有改善，不能立刻判定它無關。問題可能只在特定文章、使用者權限或某個後台頁面觸發。也要檢查佈景主題來源；切換到 WordPress 預設佈景主題只能在測試環境進行，正式站不要直接更換而影響前台版面。

常見誤判、回復與安全注意事項

查詢數量多不等於一定慢：應以總耗時、單筆耗時及使用者實際感受綜合判斷。
慢查詢不一定是外掛唯一責任：外掛可能只是觸發大型資料表，仍需確認資料量與索引狀況。
停用後功能消失是預期結果：重新啟用原外掛即可回復；若設定被改動，應依維護前備份或外掛設定記錄還原。
不要在正式站長期開啟：Query Monitor 會增加觀察成本，並可能顯示 SQL、網址、使用者與錯誤細節。只讓可信任的管理員使用，排查完成後立即停用並移除。

Query Monitor 的結果應保存為維護紀錄：受影響頁面、最慢查詢、元件名稱、測試前後耗時與回復方式。若需要進一步整理後台介面，也可參考WordPress 後台效能與介面簡化，但不要把移除介面元件當成資料庫問題的替代方案。