WordPress wp_options autoload 排查｜後台變慢、資料庫與快取維護紀錄

WordPress 後台突然變慢時，第一個直覺常常是懷疑主機、PHP 版本、外掛太多或 CDN 快取沒有打開。這些都可能是原因，但還有一個很常被忽略的層：wp_options 裡標記為 autoload = yes 的資料。

autoload 的設計是讓 WordPress 啟動時一次載入常用設定，例如網站名稱、佈景主題設定、外掛必要設定。問題是，若外掛把大量暫存、紀錄、舊設定或 serialized payload 放進 autoload，前台與後台每個 request 都可能背著一包不必要的資料。

這篇不是「看到 autoload 大就刪掉」的清單，而是一份維護紀錄：先觀察症狀，再查資料庫證據，最後用可回滾的方式驗證是否真的改善。

先記錄症狀，不要直接清資料表

排查前先寫下 observable evidence，避免清完資料才發現真正問題在 PHP error、物件快取或外部 API timeout。

Observe:
- /wp-admin/ 進入文章列表需要 6 到 9 秒。
- 前台首頁偶爾正常，後台所有頁面都偏慢。
- 最近更新過 SEO 外掛與表單外掛。
- 主機 CPU 沒有長時間滿載，但 PHP-FPM request 時間拉長。

這些紀錄會幫你判斷：問題是整站慢、只有後台慢、只有特定頁面慢，還是某個外掛動作觸發時才慢。

用 WP-CLI 先看 autoload 總量

若主機可用 WP-CLI，可以先用 option 指令或 SQL 查詢抓大方向。不同環境的資料表前綴不一定是 wp_，正式查詢前要先確認 $table_prefix。

wp db query \
"SELECT ROUND(SUM(LENGTH(option_value))/1024/1024, 2) AS autoload_mb
 FROM wp_options
 WHERE autoload = 'yes';"

這個數字不是唯一判準，但它能回答一個很重要的問題：WordPress 每次啟動時，大約要載入多少 options 資料。如果 autoload 已經從幾 MB 膨脹到數十 MB，就值得繼續往下查。

找出最大但不要立即刪除

下一步是列出最大的 autoload options，先辨識來源。

wp db query \
"SELECT option_name,
        ROUND(LENGTH(option_value)/1024, 1) AS size_kb
 FROM wp_options
 WHERE autoload = 'yes'
 ORDER BY LENGTH(option_value) DESC
 LIMIT 20;"

看到結果後，我會先把每個 option 分成幾類：

類型	判斷方式	處理態度
WordPress 核心設定	站台、佈景、rewrite、widget 等	不手動刪
外掛必要設定	option 名稱含外掛前綴，文件有提到	先查文件
過期 transient / cache	名稱像暫存或 migration log	可評估清理
巨大 serialized 資料	value 很大且來源不明	先備份再測

關鍵是：option_name 看起來像外掛資料，不代表它可以刪；也不代表它不能刪。需要知道它是設定、快取、log 還是 migration 殘留。

清理前先做可回滾備份

任何資料庫清理都應該先讓回滾路徑存在。最基本的方式是匯出整個資料庫，或至少匯出即將處理的 options。

wp db export before-autoload-check.sql

wp db query \
"SELECT option_name, option_value, autoload
 FROM wp_options
 WHERE autoload = 'yes'
 ORDER BY LENGTH(option_value) DESC
 LIMIT 20;" \
> autoload-top20-before.tsv

若是在正式站，還要確認備份檔放在哪裡、誰能下載、是否含個資、是否需要加密與刪除週期。維護紀錄裡不要只寫「已備份」，要寫備份檔名、時間與還原方式。

改動策略：先停用 autoload，再決定是否刪除

很多情況下，第一步不一定是刪 option，而是把確定不需要每次載入的 option 改成 autoload = no，並觀察站台是否正常。

UPDATE wp_options
SET autoload = 'no'
WHERE option_name = 'example_large_plugin_cache';

這類操作必須非常保守：

不處理 WordPress 核心 option。
不處理登入、安全、付款、會員、語言切換等高風險外掛資料。
一次只改少量且有明確來源的 option。
修改後立刻清除 object cache / page cache，避免看到舊狀態。

如果 option 明確是外掛過期暫存，且外掛文件或支援討論確認可重建，再考慮刪除。否則保留資料，只降低 autoload，風險通常比較小。

Verify：用同一組頁面重測

清理後不要只憑感覺說「好像變快」。至少用同一組頁面重新測一次。

for url in \
  "https://example.com/" \
  "https://example.com/wp-admin/" \
  "https://example.com/wp-json/";
do
  curl -L -sS -o /dev/null \
    -w "%{http_code} %{time_total} %{content_type} %{url_effective}\n" \
    "$url"
done

我會把結果寫成這種格式：

Verify:
- autoload total: 18.7 MB -> 5.4 MB
- /wp-admin/edit.php: 7.8s -> 2.1s
- /wp-json/: 200 application/json
- 前台首頁、文章頁、登入流程與外掛主要功能已人工抽查

如果速度沒有改善，也是一個重要結果：表示 autoload 不是主要瓶頸，應該回頭查慢查詢、PHP error log、外部 API、物件快取或特定外掛 hook。

把資料庫維護寫成 decision log

最後，別讓這次排查只留下幾行終端機歷史。建議把它整理成 decision log：

症狀：哪些頁面慢、何時開始、誰回報。
證據：autoload 總量、最大 options、PHP / MySQL / cache 狀態。
變更：改了哪些 option、為什麼判斷低風險。
回滾：備份檔、還原命令、負責人。
驗證：前後時間、狀態碼、內容類型、人工抽查項目。
後續：是否需要移除外掛、升級主機、改 object cache 或調整排程。

這樣做的好處是，下一次 WordPress 後台變慢時，不需要重新猜測；可以先查過去的 decision log，知道哪些 option 曾經膨脹、哪些外掛會留下殘留資料，以及哪些操作被證明有效或無效。

小結

wp_options autoload 排查的重點不是追求最低數字，而是降低每個 request 不必要的負擔，同時保留可回滾的維護證據。對長期經營的內容站來說，真正有價值的不是一次清掉多少資料，而是建立一套不會誤刪、不會靠猜、也能被下一位維護者接手的排查流程。

WordPress wp_options autoload 排查：從後台變慢到資料庫證據的維護紀錄