前言：虛擬主機上的資料庫連線噩夢

許多開發者在使用 Linux 虛擬主機（PHP + MySQL 架構）時，都曾遭遇「Can't connect to MySQL server」的錯誤訊息。這類問題往往具有間歇性、難以重現的特徵，讓人抓狂不已。本文將從實戰案例出發，層層剖析連線失敗的核心成因，並提供可落地的優化策略。

案例還原：從週發到日發的惡化過程

一位開發者分享了其真實經歷：網站上線一年運作正常，半年前開始每週出現 1-2 次連線失敗，需聯繫主機商重啟 MySQL 服務才能恢復。錯誤日誌顯示：

Warning: mysql_connect(): Can't connect to MySQL server on 'xx.xx.xx.xx' (4)

主機商聲稱同主機其他網站正常，將責任推給程式碼。開發者嘗試將 mysql_connect() 改為持久連線 mysql_pconnect()，問題緩解半個月，但流量回升後錯誤頻率暴增至每天多次，甚至重啟服務也無效。

核心成因深度解析

1. 連線資源耗盡：無聲的殺手

虛擬主機環境下，MySQL 的 max_connections 參數通常受限（預設 100-151）。若程式碼未妥善釋放連線，或單頁查詢過多、迴圈中重複查詢，極易耗盡連線池。錯誤代碼 (4) 往往對應 CR_CONN_HOST_ERROR，實際上可能是伺服器拒絕新連線的偽裝表現。

2. DNS 解析與網路路徑問題

使用 IP 或域名作為 Host 而非 localhost，會強制連線經過 TCP/IP 協議棧，引入 DNS 解析延遲與網關故障風險。若改用 localhost，MySQL 客戶端庫會自動嘗試 Unix Socket 連線，繞過網路層，顯著降低失敗率。

3. 持久連線的雙面刃

mysql_pconnect() 重用連線雖減少握手開銷，但若連線處於睡眠狀態超過 wait_timeout（預設 8 小時），伺服器會主動斷開，導致下次請求拿到失效連線。流量驟增時，殭屍連線佔用槽位，加劇資源爭搶。

實戰優化方案

優化一：強制使用 Socket 連線

// 錯誤示範
$host = '192.168.1.100'; // 或域名

// 正確示範
$host = 'localhost'; // 自動走 Unix Socket
// 或明確指定 socket 路徑
$host = 'localhost:/var/run/mysqld/mysqld.sock';

優化二：查詢結構重構

• 消除 N+1 查詢：迴圈中查詢改為 JOIN 或 IN 子查詢一次性獲取
• 單頁連線數控制：核心頁面 ≤ 1 次連線，複雜頁面 ≤ 3 次
• 引入連線池：若使用 PHP-FPM，配合 mysqli 或 PDO 的持久連線池特性

優化三：關鍵參數調整（需主機商配合）

參數	建議值	說明
max_connections	300-500	視記憶體而定，每連線約 2-3MB
wait_timeout	60-300	縮短閒置連線存活時間，釋放槽位
interactive_timeout	60-300	同步調整
max_user_connections	50-100	限制單用戶佔用，防單站拖垮全庫

優化四：啟用慢查詢日誌與監控

# my.cnf
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1
log_queries_not_using_indexes = 1

定期分析 mysqldumpslow -s t /var/log/mysql/slow.log，針對性加索引、改寫 SQL。

避坑指南：常見誤區

1. 誤以為 pconnect 萬能：未配合 mysql_ping() 心跳檢測，極易拿到斷開的連線
2. 忽略連線字元集協商：每次連線執行 SET NAMES utf8mb4 會增加 RTT，建議在連線字串指定 charset=utf8mb4
3. 未處理重連邏輯：PDO::ATTR_ERRMODE 設為 ERRMODE_EXCEPTION，捕獲異常後重試 1-2 次

總結

MySQL 連線失敗多為「資源耗盡」與「網路路徑不佳」的疊加效應。優先改用 localhost + Socket 連線、重構高頻頁面查詢邏輯、推動主機商調整核心參數，三管齊下可解決 90% 以上案例。若虛擬主機限制過多，遷移至雲資料庫（如 RDS、Cloud SQL）獲得獨享資源與自動運維，才是長久之計。