如何解決在 WordPress 當中遇到建立數據庫連線時發生錯誤（Establishing a Database Connection）的情況

Facebook Line Messenger Telegram

你有沒有曾經遇過，早上起床打開自己的 WordPress 網站，準備開始寫文章，結果映入眼簾的不是熟悉的首頁，而是一行冷冰冰的白色字體寫著「建立資料庫連線時發生錯誤（Error Establishing a Database Connection）」？

那個瞬間，心跳真的會漏一拍。我還記得自己好幾年前開始用 WordPress 架站時遇到這個錯誤的狀況，腦中閃過的第一個念頭是「我的網站是不是被駭了？」、「我的文章是不是全沒了？」。後來處理了不下上百次這個問題之後才明白，這其實是 WordPress 最常見也最好解決的錯誤之一。

這個錯誤的本質很簡單：你的 WordPress 網站（PHP 程式碼）沒辦法跟後端的 MySQL 或 MariaDB 資料庫建立起連線。就像你去咖啡店點餐，但廚房突然斷電了，服務生沒辦法把你的單子送進去，你也就拿不到餐點。WordPress 的工作原理也是一樣，所有的文章內容、設定、使用者資料都存在資料庫裡，如果 PHP 引擎連不上資料庫，整個網站就會直接罷工。

好消息是，根據我多年幫人排錯的經驗，超過八成的情況都能在十分鐘內搞定，不需要高深的技術背景。只要你按部就班跟著接下來的排查流程走，基本上不太需要求助主機商的技術支援。

注意

在進行以下任何操作之前，請確保你有先備份過一次網站。如果你還沒有安裝備份外掛，強烈建議先參考我們的 UpdraftPlus 備份教學，養成定期備份的好習慣。

要有效解決這個錯誤，我們得先搞清楚 WordPress 是怎麼運作的。簡單來說，WordPress 是一個由 PHP 程式語言驅動的內容管理系統，它把所有的文章、頁面、設定、使用者帳號、外掛設定等等，全部儲存在一個 MySQL 或 MariaDB 資料庫裡面。每當有訪客瀏覽你的網站，WordPress 的 PHP 引擎就會去向資料庫「要資料」，然後組合成網頁呈現給訪客看。

所以當這條「PHP 到資料庫」的連線斷了，整個網站就完全無法運作。這條連線會斷掉，背後常見的原因有以下幾種：

常見原因一：資料庫帳號密碼不匹配

這大概是我看過最常見的原因了。WordPress 的資料庫連線資訊全部記錄在一個叫 wp-config.php 的檔案裡，包括資料庫名稱（DB_NAME）、使用者名稱（DB_USER）、密碼（DB_PASSWORD）和主機位址（DB_HOST）。如果你曾經在主機控制面板裡修改過資料庫密碼，但忘了同步更新 wp-config.php 這個檔案，WordPress 就會一直拿舊密碼去連線，自然連不上。

常見原因二：MySQL 或 MariaDB 服務掛掉了

資料庫伺服器本身就是一個持續運作的服務程式。有時候因為伺服器記憶體不足、系統更新、或單純的程式錯誤，MySQL/MariaDB 服務會意外停止。當資料庫服務停了，不管你的 wp-config.php 設定再怎麼正確也沒用，因為根本沒有人在家回應連線請求。

常見原因三：資料庫檔案損壞

WordPress 的資料庫裡有十幾個資料表，其中 wp_options 這個資料表特別關鍵，它儲存了網站所有的基本設定。如果因為伺服器突然斷電、硬碟空間滿了、或主機商進行了不當的維護，導致某些資料表損壞，WordPress 在讀取時就會出錯，間接表現為資料庫連線失敗。

常見原因四：虛擬主機負載過高

如果你用的是比較便宜的共用虛擬主機，同一台伺服器上可能塞了幾百個網站。當某個鄰居網站突然流量暴增，或者你自己的網站遇到了意料之外的流量高峰，伺服器的資源被吃光，MySQL 可能會開始拒絕新的連線請求。這時候你就會看到這個錯誤。這種狀況通常是暫時性的，過一陣子流量降下來就會恢復，但如果頻繁發生，就得認真考慮換一家品質更好的主機商了。

常見原因五：伺服器遷移後設定未更新

有時候你把網站從 A 主機搬到 B 主機，檔案都傳好了，資料庫也匯入了，但忘了更新 wp-config.php 裡的連線資訊。特別是 DB_HOST 這個值，不同主機商可能會有不同的設定。有些是 localhost，有些是一個 IP 位址，有些則是一個內部網域名稱。搬完家忘了改鑰匙，當然進不去門。如果你剛好正在考慮註冊新網域或遷移網站，搬家完成後千萬記得檢查 wp-config.php 的設定。

常見原因六：外掛或佈景主題的資料庫操作異常

某些設計不良或久未更新的外掛，可能會產生異常的資料庫查詢，長時間佔用連線不釋放，最終耗盡 MySQL 的最大連線數。尤其是一些舊版的快取外掛或資料庫優化外掛，在某些特定條件下容易觸發這類問題。

常見原因七：資料庫使用者權限問題

資料庫使用者的權限如果被意外重設或變更，就算帳號密碼完全正確，MySQL 也會因為權限不足而拒絕連線。這種情況比較少見，但如果你用的是安全性較高的主機方案，某些主機商進行系統升級或維護之後偶爾會發生。

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

打開瀏覽器，在你的網址後面加上 /wp-admin/，例如你的網站是 example.com，那就輸入 example.com/wp-admin/。看看後台登入頁面會出現什麼。

這裡會有三種不同的結果，每一種指向不同的問題方向：

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

把這個判斷結果記下來，接下來的步驟會根據你的情況來引導你走最快的修復路徑。

步驟二：檢查 wp-config.php 資料庫憑證設定

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

你需要透過 FTP/SFTP 軟體（像是 FileZilla）、主機控制面板的檔案管理器，或是 SSH 連線來存取這個檔案。如果你從來沒用過 FTP，可以從主機商的教學開始，大部分都有提供圖文並茂的指引。找到 wp-config.php 之後，用純文字編輯器打開它（不要用 Word），找到這幾行：

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 設定：

主機商	DB_HOST 值	備註
Bluehost	localhost	最常見的設定
SiteGround	localhost	可從 Site Tools 確認
Hostinger	localhost	hPanel 裡可查看
Kinsta	localhost	使用 Google Cloud 基礎架構
A2 Hosting	localhost	cPanel 可確認
WPX Hosting	localhost	自建基礎架構
Sugarhosts	localhost	cPanel 可確認
DreamHost	mysql.example.com	需替換為實際的資料庫主機名稱
iPage	username.ipagemysql.com	需替換為你的 iPage 帳號
HostPapa	localhost	cPanel 可確認
HostGator	localhost	cPanel 可確認
GreenGeeks	localhost	cPanel 可確認
WPWebHost	localhost	cPanel 可確認
戰國策	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 修復資料庫

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

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

安全性警告

repair.php 這個頁面不需要登入就能存取。也就是說，任何人只要知道這個網址，都能對你的資料庫執行修復操作。這就是為什麼修復完成後，一定要記得移除 WP_ALLOW_REPAIR 的設定。我看過不少人修好之後就忘了這件事，等於是留了一扇沒鎖的門。

修復完成之後，重新整理你的網站首頁，看看是不是恢復正常了。如果恢復了，那就搞定了。如果還是有問題，別急，還有其他方法可以試。

步驟四：檢查 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：使用者名稱或密碼不正確，回到步驟二檢查憑證。
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 指令直觀很多。

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

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

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

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

步驟七：排查外掛與佈景主題衝突

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

外掛排查：二分搜尋法

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

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

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

佈景主題排查

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

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

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

虛擬主機負載與主機品質的影響

講了這麼多排查方法，其實有一個根本性的問題很多人沒意識到：你的主機品質，很大程度上決定了你遇到「建立資料庫連線時發生錯誤」的頻率。

我用過的虛擬主機少說也有十幾家，從免費的 000webhost、5GBFree，到入門級的 iPage、HostPapa，再到中高階的 Bluehost、SiteGround、WPX Hosting，以及企業級的 Kinsta。不同價位的主機，在資料庫穩定性上的差異確實非常明顯。

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

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

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

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

2026 年 WordPress 虛擬主機推薦懶人包 – 熱門 17 個 WordPress 主機費用、速度與方案完整評價與教學

預防「建立資料庫連線時發生錯誤」的最佳實踐

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

定期備份網站與資料庫

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

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

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

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

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

選擇品質可靠的主機商

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

定期優化資料庫

WordPress 用久了，資料庫裡面會累積很多垃圾：文章修訂版本、被標記為垃圾的留言、過期的暫存資料等等。這些垃圾會讓資料庫越來越肥，查詢越來越慢。定期清理這些無用資料，可以保持資料庫的健康狀態。不要安裝來路不明的資料庫優化外掛，直接用 phpMyAdmin 手動清理或者用可靠的方案會更安全。

避免安裝過多外掛

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

使用 CDN 分散流量壓力

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

常見問題 FAQ

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

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

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

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

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

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

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

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

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

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

如何在不影響線上網站的情況下測試修復？

最好的做法是建立一個測試環境（staging site）。很多主機商（像是 Kinsta、SiteGround）都提供一鍵建立 staging 環境的功能，你可以先在 staging 上測試修復方案，確認沒問題再到正式環境上操作。如果你的主機商沒有這個功能，InstaWP 是一個免費的替代方案，可以在幾秒鐘內建好一個 WordPress 測試站。

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

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

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