WordPress「建立資料庫連線時發生錯誤」是什麼意思，又該怎麼修

你打開網站，每一個頁面——前台和 wp-admin 都一樣——都被換成一行灰色的句子：建立資料庫連線時發生錯誤。 什麼都顯示不出來，因為根本無從顯示。WordPress 連組建頁面那一步都還沒走到。

有一個心智模型能讓這個問題很快修好。WordPress 把你的全部內容——文章、頁面、設定、使用者——都存在 MySQL 資料庫裡，而不是存在檔案裡。每一次請求，它都會從 wp-config.php 讀取四項登入資訊，連上那個資料庫，取出需要的東西。這個錯誤代表連線被嘗試了，然後被拒絕了。要修好它，就是弄清楚它為什麼被拒絕，而可能性只有三種。

三種原因，依可能性由高到低

1. wp-config.php 裡某項憑證填錯了——通常是換主機造成的。
2. 資料庫伺服器當機或過載——通常是在你這邊什麼都沒動的情況下發生的。
3. 資料庫損毀——比較少見，而且它表現出來的樣子也不一樣。

照這個順序逐一排查。

步驟 1：核對這四項憑證

用 SFTP 或主機的檔案管理員打開網站根目錄的 wp-config.php。有四行定義了這個連線：

define( 'DB_NAME', 'your_database_name' );
define( 'DB_USER', 'your_database_user' );
define( 'DB_PASSWORD', 'your_database_password' );
define( 'DB_HOST', 'localhost' );

這四項都必須和主機分配給你的完全一致。打開主機控制台的資料庫一欄（在 cPanel 裡叫「MySQL Databases」），逐字比對：

• DB_NAME — 主機常常會在名稱前面加上你的帳號前綴，例如 cpaneluser_wpdb。這個前綴是名稱的一部分。
• DB_USER — 同樣有前綴，而且這個使用者必須被指派到那個資料庫上，不能只是存在。
• DB_PASSWORD — 最常見的元凶。沒把握就在控制台裡重設，再把新值貼進去。留意結尾的空格，或是被自動換成的彎引號。
• DB_HOST — 別理所當然地填 localhost。很多主機用的是專門的資料庫伺服器，位址像 mysql.yourhost.com，有時還帶 :port。控制台會顯示正確的值。

既然這四個值正好就住在這個檔案裡，那麼重新產生一份乾淨、引號都正確的 wp-config.php，最穩妥的辦法就是用 wp-config.php 產生器——填好四個資料庫欄位，把產生的結果覆蓋到舊的那一段上。

幾乎每一次搬遷之後，光是這一步就能修好這個錯誤，因為在舊主機上正確的憑證，到了新主機上就成了錯的。

步驟 2：確認資料庫伺服器真的在運作

如果憑證沒錯，錯誤卻還在——尤其是它在你沒做任何更動的情況下自己冒出來的——那麼嫌疑就落在資料庫伺服器本身。

在共享主機上這很常見，而且通常是暫時的：MySQL 服務在流量尖峰時被壓垮，或是達到每個帳號的連線數上限，開始拒絕新的連線。它一般幾分鐘內就會恢復。在採取任何激烈手段之前，先稍等一下再重新整理。

要脫離 WordPress、單獨測試憑證到底有沒有效，可以在 wp-config.php 旁邊放一個很小的腳本：

<?php
$link = mysqli_connect('localhost', 'your_database_user', 'your_database_password');
if (!$link) {
    die('Connection failed: ' . mysqli_connect_error());
}
echo 'Connected — the server and credentials are fine.';

用你真實的 DB_HOST、DB_USER 和 DB_PASSWORD。如果它印出 Connected，代表你的登入資訊是好的，問題在別處（資料庫損毀，步驟 3）。如果它印出連線錯誤，訊息會告訴你是哪一種：「Access denied」表示使用者或密碼錯了；「Can’t connect to MySQL server」表示主機位址錯了，或是服務真的當了——該聯絡主機商了。一做完就立刻刪掉這個腳本。

步驟 3：修復損毀的資料庫

有一個跡象能把損毀和連線問題區分開來：前台打得開，但 wp-admin 出錯，或是反過來。如果連線真的被拒絕了，兩邊都應該是死的。像這樣一邊好一邊壞，指向的是資料表損毀。

WordPress 內建了一個修復工具。在 wp-config.php 裡、「停止編輯」那行註解之上，加上一行：

define( 'WP_ALLOW_REPAIR', true );

接著在瀏覽器裡直接開啟這個 URL：

https://yoursite.com/wp-admin/maint/repair.php

這個頁面不需要登入就能開啟——這正是它的用意，因為你可能已經被鎖在外面——它提供「Repair Database」和「Repair and Optimize Database」兩個選項。執行它。

然後立刻從 wp-config.php 裡刪掉那一行。 只要它還在，網路上的任何人都能開啟那個 URL，對你的資料庫執行一次修復。這不是可做可不做的收尾，而是在堵上你剛剛打開的一個洞。

步驟 4：當修復頁面自己都連不上

如果修復頁面自己也顯示連線錯誤，那就沒什麼好修的了——資料庫根本連不上，於是你又回到了步驟 1 或步驟 2。到了這一步，可靠的做法是從主機最近一次備份還原資料庫。大多數控制台都會每天自動保留資料庫快照；從昨晚的狀態還原，幾乎總比去追一個你連都連不上的損毀更快、更安全。

可以放心略過的建議

「直接重裝 WordPress 吧。」 這個錯誤關乎的是資料庫連線，不是核心檔案。重裝只會把那些本來好好的檔案換掉，而對真正壞掉的地方一點都碰不到。

「把 PHP 記憶體上限調高。」 記憶體耗盡是另一種錯誤，訊息也不一樣。調高上限對一個被拒絕的資料庫連線毫無作用，只會掩蓋你根本沒去核對憑證這件事。

「清一下快取。」 這個失敗發生在 PHP 裡，早於任何快取能回傳頁面的時刻。連線被拒絕期間，清快取什麼都改變不了；只有在網站恢復之後才值得做。

「直接改資料庫來修好它。」 在還沒確認連線到底通不通之前，就跑去 phpMyAdmin 手動改資料表，正是把一次暫時的故障變成永久資料遺失的做法。先確認連線；資料最後才碰，而且只從備份裡碰。

還是搞不定？

如果測試腳本驗證了憑證、伺服器在運作、修復也連得上並回報沒有錯誤，網站卻還是顯示這條訊息，那剩下的嫌疑對象就是某個用自己獨立連線去存取資料庫的外掛——一個存了過時主機位址的快取外掛或資料庫外掛。用 SFTP 把 wp-content/plugins 改名為 plugins-off 來排除它。如果錯誤消失了，就把外掛一個一個裝回去，直到它再次出現。