如何解決 WordPress「建立資料庫連線時發生錯誤」（Error Establishing a Database Connection）

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

「建立資料庫連線時發生錯誤」代表你的 WordPress 沒辦法連上 MySQL/MariaDB 資料庫。八成以上的情況能在十分鐘內修好，不需要寫程式。

你可能剛打開自己的 WordPress 網站，結果看到的不是熟悉的首頁，而是一行白底黑字寫著「Error Establishing a Database Connection」。這個畫面確實會讓人心跳漏一拍，但根據我多年幫人排錯的經驗，這是 WordPress 最常見也最好解決的錯誤之一。

這個錯誤的本質很簡單：你的 WordPress 網站（PHP 程式碼）沒辦法跟後端的 MySQL 或 MariaDB 資料庫建立起連線。WordPress 的所有文章內容、設定、使用者資料都存在資料庫裡，如果 PHP 引擎連不上資料庫，整個網站就會直接罷工。

先判斷問題範圍：前台還是後台

動手修之前，先做一個關鍵判斷：搞清楚問題是出在前台還是後台。這個判斷會大幅縮小後續的排查範圍。

打開瀏覽器，在你的網址後面加上 /wp-admin/，看看後台登入頁面會出現什麼。會有三種結果：

• 後台也出現「建立資料庫連線時發生錯誤」：代表問題是整體性的資料庫連線問題，可能是帳號密碼錯了、MySQL 服務停了、或是主機負載過高。從「檢查 wp-config.php 資料庫憑證設定」開始查。
• 後台出現「One or more database tables are unavailable. The database may need to be repaired.」：資料庫裡有資料表損壞了。直接跳到「啟用 WordPress 內建資料庫修復功能」。
• 後台可以正常進入：如果後台沒問題只有前台報錯，問題很可能出在你的佈景主題或某個外掛身上。跳到「排查外掛與佈景主題衝突」。

常見原因總覽

WordPress 的資料庫連線會斷掉，背後常見的原因有以下幾種：

檢查 wp-config.php 資料庫憑證設定

如果前後台都出現錯誤，大概率的問題就出在 WordPress 和資料庫之間的「鑰匙」不對。WordPress 把所有連線需要的資訊都放在 wp-config.php 這個檔案裡，位於 WordPress 根目錄底下。

你需要透過 FTP/SFTP 軟體（像是 FileZilla）、主機控制面板的檔案管理器，或是 SSH 連線來存取這個檔案。如果你從來沒用過 FTP，可以從主機商的教學開始，大部分都有提供圖文並茂的指引。

wp-config.php 四個關鍵常數說明

這四個常數是 WordPress 和資料庫溝通的全部憑證。任何一個填錯了，網站就會直接報「建立資料庫連線時發生錯誤」。

• DB_NAME：資料庫的名稱。如果你在 cPanel 或 Plesk 裡建立過資料庫，名稱通常會長得像 username_wp823 這種格式。去你的主機控制面板裡找「MySQL 資料庫」頁面，核對名稱是否一致。
• DB_USER：資料庫的使用者名稱。注意，這跟你的 WordPress 後台帳號完全不同，這是 MySQL 層級的使用者。一樣在主機控制面板的 MySQL 頁面可以找到。
• DB_PASSWORD：資料庫使用者的密碼。這是我看過最常出錯的欄位。如果你曾經改過資料庫密碼，這裡一定要同步更新。要注意密碼裡面如果有特殊字元（像是 $、&、#），有時候會因為複製貼上的過程中被截斷或轉義，導致實際寫入的密碼跟你以為的不一樣。
• DB_HOST：資料庫伺服器的位址。大多數共用虛擬主機的值都是 localhost，但不是全部。

核對的方式很直接：打開你的主機控制面板，找到 MySQL 資料庫的頁面，把那邊顯示的資料庫名稱、使用者名稱跟 wp-config.php 裡的值逐字比對。密碼的面板上不會直接顯示，但你可以建立一個新的資料庫使用者，設定一個確定的密碼，然後把新使用者的資訊填進 wp-config.php 試試看。

各主機商的 DB_HOST 預設值對照表

DB_HOST 這個值，絕大多數主機商的預設值都是 localhost，但有少數主機商會使用不同的值：

如果你不確定自己的 DB_HOST 該填什麼，最保險的做法是登入你的主機控制面板，找到「MySQL 資料庫」或類似名稱的頁面，那邊通常會顯示正確的資料庫主機位址。也可以直接問主機商的技術支援，這是他們每天都被問的問題，問了不丟臉。

修改完 wp-config.php 之後，存檔，然後重新整理你的網站。如果錯誤訊息消失了，問題就是出在憑證設定。如果還是不行，繼續往下看。

啟用 WordPress 內建資料庫修復功能

如果在檢查 /wp-admin/ 的時候，你看到的是「One or more database tables are unavailable. The database may need to be repaired.」，那問題就很明確了：你的資料庫裡有資料表損壞了。WordPress 其實內建了一個很方便的修復工具，不需要你自己去操作 SQL 指令。

如何使用 repair.php 修復資料庫

操作流程很簡單，但有一個安全性的眉角要注意：

1. 用 FTP 或檔案管理器打開 wp-config.php。
2. 找到 /* That's all, stop editing! Happy blogging. */ 這行註解，在它的上方加入以下這行程式碼：
   define('WP_ALLOW_REPAIR', true);
3. 存檔。
4. 打開瀏覽器，前往 你的網址/wp-admin/maint/repair.php。例如你的網站是 example.com，那就輸入 example.com/wp-admin/maint/repair.php。
5. 你會看到兩個選項：「修復資料庫」和「修復並優化資料庫」。建議選「修復並優化資料庫」，一次把兩件事都做了。
6. 等它跑完。通常幾秒到幾分鐘不等，取決於你的資料庫大小。
7. 關鍵步驟：修復完成後，回到 wp-config.php，把剛才加的那行 define('WP_ALLOW_REPAIR', true); 刪除，然後存檔。

修復完成之後，重新整理你的網站首頁，看看是不是恢復正常了。如果恢復了，那就搞定了。如果還是有問題，繼續往下。

檢查 MySQL/MariaDB 服務狀態

有時候問題不在 WordPress 這邊，而是資料庫伺服器本身停了。MySQL 或 MariaDB 就是那個負責接收和處理所有資料庫查詢的程式，如果它停了，你的 WordPress 再怎麼正確設定也連不上。

虛擬主機用戶的判斷方式

如果你用的是共用虛擬主機（像是 FastComet、HostGator 這類），你多半沒有 SSH 權限可以直接檢查 MySQL 服務狀態。不過你可以從以下幾個面向判斷：

• 登入主機控制面板（cPanel、hPanel、Site Tools 等），試試看能不能開啟 phpMyAdmin。如果 phpMyAdmin 也連不上資料庫，那很可能是 MySQL 服務本身出了問題，這時候直接聯絡主機商的技術支援是最快的解法。
• 檢查主機商的狀態頁面（Status Page）。很多大型主機商都有公開的服務狀態頁面，會即時顯示是否有已知的伺服器問題。如果是主機商那邊的系統問題，你什麼都不用做，等他們修好就行。
• 詢問主機商技術支援：「我的 MySQL 服務是否正常運作？」這聽起來很基本，但真的很有效。好的主機商通常幾分鐘內就會回覆你。

VPS 或專屬主機用戶的操作方式

如果你是自己管理伺服器（像是用EasyEngine、RunCloud 或 ServerPilot 架站），你可以透過 SSH 連線來檢查和重啟 MySQL 服務。

重啟之後，再檢查一下狀態是不是變成 active (running)。如果是，重新整理你的 WordPress 網站試試看。

另一個值得檢查的指標是 MySQL 的最大連線數（max_connections）。當網站流量突然暴增，或是某個外掛產生了異常多的資料庫查詢，連線數可能會被佔滿，導致新的連線請求被拒絕。你可以透過 phpMyAdmin 執行以下 SQL 查詢來查看目前的連線數：

如果 Threads_connected 的值很接近 max_connections，那就有可能是連線數不夠用。這時候的解決方向要嘛是增加 max_connections 的值，要嘛是找出哪個頁面或外掛吃了太多連線。

開啟 WP_DEBUG 取得詳細錯誤資訊

到目前為止，如果你試過前面的方法都沒有解決問題，那就需要更深入地了解到底是哪裡出了問題。WordPress 有一個內建的除錯模式，可以幫你把錯誤訊息記錄下來，而不是只給你看一個籠統的「建立資料庫連線時發生錯誤」。

打開 wp-config.php，找到這一行（通常在檔案的前半段）：

把它改成：

這樣設定的效果是：開啟除錯模式，把錯誤訊息寫入 wp-content/debug.log 這個檔案，但不會在網頁前端顯示出來（避免影響使用者體驗和洩漏伺服器資訊）。

存檔後，重新整理幾次你的網站，然後去查看 wp-content/debug.log 的內容。你可能會看到以下幾種常見的錯誤訊息：

• Access denied for user：使用者名稱或密碼不正確，回到 wp-config.php 檢查憑證。
• Unknown database ‘xxx’：資料庫名稱不存在，可能是打錯字了或者資料庫根本沒有被建立。
• Too many connections：MySQL 的連線數已經滿了，這通常是主機資源不足的問題。
• Can’t connect to MySQL server on ‘xxx’：DB_HOST 設定不正確，或者 MySQL 服務沒有在運行。
• Table ‘xxx’ is marked as crashed：資料表損壞，用修復功能處理。

找到具體的錯誤訊息之後，對症下藥就快多了。除錯完成之後，記得把 WP_DEBUG 改回 false，或者至少確認 WP_DEBUG_LOG 關閉，免得 debug.log 一直膨脹佔用空間。

透過 phpMyAdmin 檢查資料庫完整性

如果你的主機有提供 phpMyAdmin（絕大多數主機商都有），你可以用它來直接檢查資料庫的狀態。phpMyAdmin 是一個網頁版的資料庫管理工具，操作起來比下 SQL 指令直觀很多。

1. 從你的主機控制面板（cPanel、Plesk、Site Tools 等）找到並點開 phpMyAdmin。
2. 在左側欄位中，選擇你的 WordPress 所使用的那個資料庫（名稱應該跟 wp-config.php 裡的 DB_NAME 一樣）。
3. 你會看到一串資料表列表，像是 wp_posts、wp_options、wp_users 等等。檢查每個資料表前面是不是有「使用中」或損壞的標記。
4. 如果看到有問題的資料表，勾選它們，然後在下方的下拉選單中選擇「修復資料表」。

這裡要特別提一個我遇過好幾次的狀況：wp_options 資料表異常膨脹。wp_options 是 WordPress 存放所有設定值的地方，正常情況下大小通常在幾 MB 以內。但如果某些外掛（特別是免費的快取外掛或統計外掛）在 wp_options 裡塞了大量的暫存資料又不清理，這個資料表可能會膨脹到數十甚至數百 MB。這會導致資料庫查詢變慢，間接引發連線超時的錯誤。

如果你在 phpMyAdmin 裡發現 wp_options 異常大，可以檢查一下 autoload = 'yes' 的資料列數量。理想的情況下，autoload 的資料列不應該超過幾百筆。如果上千筆甚至更多，那就是該清理了。

另一個要留意的是資料庫的總大小。有些主機方案對資料庫容量是有限制的，如果你的資料庫超過了上限，MySQL 可能會變成唯讀模式甚至停止回應。這種情況在免費主機或入門級方案上特別常見。如果你發現資料庫容量快滿了，可以考慮清理無用的修訂版本、垃圾留言和過期的暫存資料，或者直接升級你的主機方案。

排查外掛與佈景主題衝突

如果後台（/wp-admin/）可以正常進入，只有前台報錯，那問題八九不離十是出在某個外掛或佈景主題身上。就算前後台都出錯，也有可能是某個外掛的異常資料庫操作吃光了所有連線資源，所以這個排查步驟在任何情況下都值得一試。

外掛排查：二分搜尋法

最快的排查方式是透過 FTP 把外掛全部停用，然後逐個恢復找出問題外掛。具體做法如下：

1. 透過 FTP 連線到你的 WordPress 主機。
2. 進入 wp-content/plugins/ 資料夾。
3. 把整個 plugins 資料夾重新命名為 plugins.bak。這樣 WordPress 就找不到任何外掛了，等同於全部停用。
4. 重新整理你的網站，看看是否恢復正常。如果恢復了，代表問題確實出在某個外掛。
5. 把資料夾名稱改回 plugins。
6. 在 plugins 資料夾裡面，把大約一半數量的外掛資料夾重新命名（比如加上 .off 後綴），然後測試網站。
7. 如果網站正常，問題就在被停用的那一半裡；如果還是報錯，問題就在還啟用的那一半裡。
8. 重複這個二分法，直到找出是哪一個外掛造成的問題。

這個方法的效率很高，就算你有 30 個外掛，最多也只需要測試 5 次（因為 2 的 5 次方是 32）。

佈景主題排查

佈景主題的排查邏輯也一樣。透過 FTP 進入 wp-content/themes/，把你目前使用中的佈景主題資料夾重新命名。WordPress 會自動切換到 Twenty Twenty-Five（或其他預設主題，前提是它必須存在於 themes 資料夾中）。如果切換後網站恢復正常，那就是原本的佈景主題有問題，可以試著重新安裝或聯絡主題開發者。

根據我的經驗，以下幾類外掛最容易引發資料庫相關的問題：

• 快取外掛：尤其是設定不當的快取外掛，可能在資料庫裡塞了大量的暫存頁面。
• 資料庫優化外掛：聽起來很諷刺，但確實有些「優化」外掛反而會把資料庫弄壞。特別是那些自動清理和修改資料表結構的外掛。
• 安全外掛：某些安全外掛的防火牆功能可能會干擾正常的資料庫連線，尤其是啟用了過於嚴格的規則時。
• 統計分析外掛：有些統計外掛會在資料庫裡記錄每一次頁面瀏覽，長時間累積下來會讓資料庫變得非常龐大。

主機品質對資料庫穩定性的影響

講了這麼多排查方法，其實有一個根本性的問題很多人沒意識到：你的主機品質，很大程度上決定了你遇到這個錯誤的頻率。

免費或超低價的共用虛擬主機，一台實體伺服器上可能同時塞了幾百個甚至上千個網站。這些網站共用同一組 CPU、記憶體和 MySQL 服務。只要其中一個網站流量暴增，整台伺服器上的所有網站都會受到影響。你可能什麼都沒做，但隔壁的某個網站在跑一個大量資料庫查詢的腳本，你的 WordPress 就連不上資料庫了。這種狀況通常幾分鐘到幾十分鐘就會恢復，但如果頻繁發生，對網站的載入速度和 SEO 排名都是很大的傷害。

怎麼判斷是不是主機品質的問題呢？一個簡單的判斷標準：

• 偶爾出現，且幾分鐘內自行恢復：多半是流量高峰或主機商在做維護，暫時性的，可以先觀察。
• 頻繁出現（一週好幾次），持續時間越來越長：這是主機資源不足的警訊，該認真考慮升級或搬家了。
• 每次出現都需要手動修復才能恢復：可能不單純是負載問題，建議用前面的方法完整排查一次。

如果你已經厭倦了三不五時就出現資料庫連線錯誤的日子，可以參考我們整理的 WordPress 虛擬主機推薦。以穩定性來說，Bluehost 在入門級主機裡的表現算是不錯的，我們也寫過一篇 Bluehost 完整教學。而如果預算許可，Kinsta 的 Google Cloud 基礎架構在資料庫可靠性上確實有明顯的優勢。

預防資料庫連線錯誤的最佳實踐

跟所有技術問題一樣，預防永遠比修復省時省力。以下是幾個實用建議，做好這些可以大幅降低遇到資料庫連線錯誤的機率。

定期備份網站與資料庫

裝一個可靠的備份外掛，設定每天自動備份資料庫，每週完整備份整個網站。UpdraftPlus 是我一直推薦的備份方案，免費版就夠用了，可以把備份自動上傳到 Google Drive、Dropbox 等雲端空間。有備份在手，就算資料庫真的出了大問題，也可以快速恢復。

使用網站監控工具即時偵測錯誤

與其等訪客告訴你網站掛了，不如主動偵測。WP Umbrella 是一個免費的 WordPress 監控工具，可以在網站出現錯誤的第一時間發送通知給你。Cloudflare 也有提供基本的網站可用性監控功能，搭配他們的 CDN 使用效果更好。

保持 WordPress 核心和所有外掛更新

很多資料庫問題的根源是外掛的程式碼有 bug。外掛開發者通常會在新版本中修復這些問題，所以保持更新是最簡單的預防方式。不過更新之前，建議先用InstaWP 這類工具建立一個測試環境，在測試環境中更新確認沒問題後，再到正式網站上操作。這樣可以避免更新後出問題的風險。

選擇品質可靠的主機商

主機品質的影響比很多人想像的大很多。如果你認真對待自己的網站，就不要在主機上省那幾十塊錢。一台穩定的主機可以幫你省下無數個半夜爬起來修網站的夜晚。可以從我們的虛擬主機評測裡面挑一家適合你預算和需求的方案。

定期優化資料庫

WordPress 用久了，資料庫裡面會累積很多垃圾：文章修訂版本、被標記為垃圾的留言、過期的暫存資料等等。這些垃圾會讓資料庫越來越肥，查詢越來越慢。定期清理這些無用資料，可以保持資料庫的健康狀態。

避免安裝過多外掛

每多裝一個外掛，就多一個可能的問題來源。建議把外掛數量控制在 15-20 個以內。如果有些功能可以用少量程式碼實現（比如加一段 functions.php 的程式碼），就不需要多裝一個外掛。這不但能降低出錯的風險，對網站速度也有正面的幫助。

使用 CDN 分散流量壓力

Cloudflare 的免費方案就可以幫你擋掉大量的靜態資源請求，減少 PHP 和資料庫的負擔。如果你的網站流量不錯，搭配一個好的快取外掛和 CDN，可以讓資料庫的負載降低到非常低的水準。我們之前寫過一篇關於如何優化 WordPress 網站速度的完整指南，裡面有更詳細的說明。

這篇文章適合誰

• WordPress 站長：網站突然出現「建立資料庫連線時發生錯誤」畫面，需要快速找出原因並修復的人。
• 剛搬完家的站長：遷移主機後忘記更新 wp-config.php 裡的資料庫連線設定，導致新站連不上資料庫。
• VPS 自管者：自己用 EasyEngine、RunCloud 等工具架站，遇到 MySQL 服務停止或連線數不夠用的情況。

如果你用的是像 Kinsta 或 SiteGround 這類代管主機，大部分的資料庫問題可以直接找技術支援處理，不過了解這些排查邏輯還是能幫你更快定位問題。

常見問題 FAQ

「建立資料庫連線時發生錯誤」會遺失網站資料嗎？

大多數情況下不會。這個錯誤只是代表 WordPress 沒辦法連上資料庫，你的文章、頁面、設定都還好好地存在資料庫裡。就像你家門鎖壞了打不開門，不代表家裡的東西不見了。只要修好連線問題，所有資料都會回來。唯一的例外是如果你的資料庫檔案真的損壞了，這時候如果有定期備份就可以快速恢復。

修復這個錯誤需要什麼技術能力？

基本的修復步驟只需要你能存取主機控制面板和使用 FTP，不需要會寫程式。最常見的修復方式就是核對 wp-config.php 裡的資料庫帳號密碼，或者用 WordPress 內建的修復功能。如果你用的是 Bluehost 或 SiteGround 這類有完善控制面板的主機，整個過程就跟改一個設定檔差不多。

為什麼修復後過一段時間又出現同樣錯誤？

這通常代表根本問題沒有被解決。如果原因是虛擬主機負載過高，只要流量再次超過主機的承載能力，錯誤就會重現。如果是某個外掛一直在搞鬼，沒有移除或更新那個外掛，問題就會反覆出現。建議用 WP_DEBUG 開啟除錯日誌，觀察 debug.log 裡面有沒有線索，從源頭解決問題。

免費主機特別容易出現這個錯誤嗎？

是的。免費主機的資源限制非常嚴格，MySQL 連線數通常只有個位數，資料庫容量可能只有幾十 MB，CPU 使用時間也有限制。如果你的網站有稍微像樣的流量，免費主機幾乎一定會出問題。如果你是拿來練習架站和學習 WordPress，免費主機可以湊合著用；但如果是要認真經營的網站，強烈建議升級到付費主機。入門級的付費主機每個月也只要兩三塊美金，但穩定性和免費主機完全是不同等級。

使用 Cloudflare 等 CDN 會導致這個錯誤嗎？

不會。CDN 和資料庫連線是完全不同的層級。CDN 處理的是靜態資源的快取和分發，資料庫連線是 PHP 和 MySQL 之間的通訊。不過有一種情況需要注意：如果你在 Cloudflare 設定了過於激進的快取規則，可能會讓你以為網站正常，但其實顯示的是快取頁面，真正的動態頁面早就掛了。定期清除快取或者用無痕模式測試，可以避免這種誤判。

這個錯誤對 SEO 排名有影響嗎？

短時間的錯誤（幾分鐘到幾小時）影響不大，Google 的爬蟲下次來的時候如果發現網站正常，就不會有什麼處罰。但如果錯誤持續超過一天以上，Google 可能會暫時降低該頁面的排名。如果持續超過一週，頁面有機率被從索引中移除，需要重新提交和等待重新收錄。所以網站的可用性監控很重要，早發現早修復，對SEO 的影響就越小。也可以搭配網站健康檢查工具，隨時掌握網站狀態。

修好之後的下一步

1. 設定自動備份：安裝 UpdraftPlus，設定每天自動備份資料庫到雲端空間（Google Drive 或 Dropbox 都可以）。判斷標準：確認備份檔案可以正常下載並還原。預期結果：未來再遇到問題時，隨時可以從備份恢復。
2. 安裝網站監控：註冊 WP Umbrella 免費方案，把你的網站加入監控。判斷標準：確認監控面板顯示網站狀態為正常（綠燈）。預期結果：網站下次出錯時，你會在第一時間收到通知。
3. 檢查主機資源是否足夠：登入主機控制面板，查看目前的資料庫容量和 CPU 使用率。判斷標準：如果資料庫容量超過方案上限的 80%，或 CPU 使用率經常在 80% 以上，就該考慮升級方案或搬家了。預期結果：你會清楚知道目前主機的健康狀態，以及是否需要採取行動。

如果你還有更多相關的問題，歡迎在下方留言和我們聊聊，也歡迎你分享出去給更多人知道遇到「建立資料庫連線時發生錯誤」的解決方法。