很多站長花心思調整主機規格、設定快取外掛，卻少有人注意到資料庫才是拖慢網站速度最難被察覺的位置。WordPress 資料庫在長期使用下會悄悄累積廢棄資料，包括修訂版本、孤立的設定選項、過期的暫存快取，這些資料不影響前台顯示，卻佔用磁碟空間、拖慢查詢效率。

讓許多人卻步的，是「清資料庫」這件事本身的風險感。刪錯一張表，網站可能直接無法運作；清得太保守，效果又有限。真正需要釐清的，是哪些資料屬於可安全廢棄、哪些絕對不能異動，以及用什麼工具能讓整個過程維持在可控範圍內。

資料庫裡的廢棄資料從哪裡來

WordPress 的資料表設計本質上偏向「保留」而非「精簡」。每次儲存文章時，系統預設會額外保留一份修訂版本（Revision）；編輯器每隔幾十秒也會自動儲存一份草稿（Autosave）。一篇文章反覆修改十幾次，wp_posts 這張表裡就會出現十幾筆對應的廢棄紀錄，連帶在 wp_postmeta 裡留下同等數量的中繼資料（Post Meta）。

這是第一個來源：撰稿與編輯行為持續產生的冗餘快照。

第二個來源是外掛的選項機制。WordPress 提供一張叫 wp_options 的表，外掛用它儲存設定值。其中有個欄位叫 autoload，標記為 yes 的選項在每次頁面請求時都會全部載入記憶體。問題在於，部分外掛解除安裝後不會清除自己在這張表裡留下的資料，而且有些開發者習慣把不需要每次載入的設定也標記為 autoload = yes。累積久了，這張表可能有數千筆記錄，每個頁面請求都要先把這些資料完整載入一遍。

第三個來源是暫存快取（Transient）。WordPress 內建一套以 wp_options 為底層的暫存機制，外掛用它儲存 API 回應、查詢結果之類的臨時資料。每筆暫存都應該帶到期時間，但過期的暫存不會自動從資料庫刪除——除非有同一個 key 的新快取寫入覆蓋，否則舊資料就一直留著。主機環境若以物件快取（Object Cache）接管暫存機制，這個問題會緩解；但多數共享主機沒有這樣的配置，wp_options 就成了積存廢棄資料的場所。

哪些表可以安心處理，哪些不能碰

wp_posts 裡的修訂版本與草稿

修訂版本（post_type = 'revision'）和自動儲存（post_status = 'auto-draft'）是最常見、也最安全的清理對象。這些紀錄的存在只是為了讓你在後台能夠恢復舊版本——一旦文章已發布且穩定，這些備份幾乎沒有實際用途。

對於流量穩定、不再頻繁修改的舊文章，保留最近 2 至 3 份修訂版本已足夠，其餘可以清除。垃圾桶裡的文章（post_status = 'trash'）同樣可以安全刪除，但務必確認沒有誤移進去的草稿。

絕對不能異動的是 post_type = 'post'、'page'、'attachment' 的正式資料，以及外掛自訂的文章類型（Custom Post Type），例如電商訂單（shop_order）、課程紀錄、會員資料等。這些資料不論看起來多舊，都不應該用清理工具批次刪除。

wp_options 的 autoload 問題

這張表需要的不是批次刪除，而是逐項分析。做法是先找出所有 autoload = yes 的選項，確認哪些是已解除安裝外掛的遺留資料、哪些是現有功能正在使用的，再做針對性處理。

一個實用的判斷基準：autoload = yes 的選項總資料量建議控制在 1 MB 以內，超過這個數字就值得深入檢查。清理前最好將整張表匯出備份，因為誤刪一個作用中的設定值，可能導致某個功能靜悄悄失效，不會有明顯的錯誤提示。

過期暫存（_transient_% 且到期時間早於現在）是這張表裡最安全的刪除對象，清理前不需要備份這個部分——即便出錯，最多是讓某個功能重新生成快取。

wp_postmeta 與孤立的中繼資料

wp_postmeta 儲存每篇文章的自訂欄位。對應的文章若已刪除，這裡的中繼資料就成了孤立記錄（Orphaned Meta）。這類資料可以清理，但要確認「文章刪除」指的是資料庫裡的物理刪除，而不只是移到垃圾桶。外掛遺留的中繼資料通常也屬於這一類。

wp_usermeta 與 wp_commentmeta 同理，孤立的記錄可以清除，但對應帳號或留言仍存在的資料不要異動。

絕對不能批次清理的區域

wp_users、wp_term_relationships、wp_term_taxonomy、wp_terms 這幾張表直接關聯到帳號、分類、標籤的結構，任何批次刪除都存在連帶損壞的風險。如有需要清理，應透過 WordPress 後台介面逐筆操作，而不是依賴資料庫清理外掛處理。

用工具操作，可控但不能省略確認步驟

WP-Optimize 的清理邏輯

WP-Optimize 的操作介面將清理項目分成「文章」「留言」「資料庫」三個頁籤，每個項目都會先顯示筆數供確認。幾個值得注意的設定：

• 修訂版本數量上限：可設定每篇文章保留幾份，建議 2 至 3 份，而非全部刪除
• 自動排程清理：適合已穩定運作的站台，每月執行一次即可；高頻修稿的站台建議手動操作
• 刪除孤立的中繼資料：這個選項需要特別確認，若有外掛使用自訂欄位且不在標準清單內，可能被誤判為孤立資料

操作前應先透過 WP-Optimize 內建的備份功能，或使用 UpdraftPlus 之類的工具完整備份資料庫，再執行清理。

Advanced DB Cleaner 的分析流程

進階資料庫清理工具（Advanced DB Cleaner）相較於 WP-Optimize，更適合需要細緻控制的情境。它的核心功能是掃描「孤立的表」——那些外掛解除安裝後遺留在資料庫裡、不再被任何程式讀寫的表。這類殘留表在換過多個外掛的舊站台相當常見。

使用時先跑掃描，取得孤立表清單，再逐一比對：確認是自己已解除安裝的外掛所留下、且不再需要保留資料的，才標記刪除。對不確定的項目，選擇保留永遠優於盲目刪除。

這個工具也提供 autoload 選項的分析報表，可以看到哪些選項佔用空間最大，方便做針對性的判斷。

操作順序與最低安全門檻

無論使用哪套工具，建議依下列順序處理：

• 清過期暫存：風險最低，立即見效，適合第一步
• 清修訂版本：效果顯著，清理前先確認保留份數設定
• 清孤立中繼資料：確認外掛狀態後再執行
• 分析 autoload：需要逐項判斷，最後處理

每次清理後，在 WordPress 後台執行一次「資料庫最佳化」（Optimize Tables）——WP-Optimize 有提供對應按鈕，phpMyAdmin 同樣可以操作。這個動作會重新整理表的索引與空間，讓查詢效率真正提升。

清理前必做的三件事

清理動作不可逆，以下確認步驟不應省略。

備份是最基本的要求。資料庫備份要存到主機以外的位置，例如本機或雲端儲存，不要只留在主機上的備份資料夾。備份完成後應確認檔案能正常還原，空備份或損壞的備份沒有任何意義。

暫存環境測試優先於正式站。如果主機有提供暫存環境（Staging），先在那裡完整跑一次清理流程，確認網站功能正常後再同步到正式站。沒有暫存環境的主機，至少選在流量低峰時段操作，這樣出問題時的修復窗口會比較寬裕。

注意外掛相依性。電商外掛（如 WooCommerce）、會員外掛、課程外掛通常會自訂文章類型，或在 wp_options 裡儲存大量設定，這類外掛的相關資料不要納入批次清理範圍。應先到對應外掛的設定頁面確認哪些欄位是它在使用的，再決定是否保留。