MySQL 頻繁崩潰？系統排查與根因分析完整指南

前言：崩潰並非無迹可尋

MySQL 正式版經過多平台測試，崩潰多源於特定環境、硬體或操作失誤。關鍵在於精確重現問題，才能快速定位並修復。本文提供系統化排查流程。

第一步：區分服務端與客戶端問題

• 執行 mysqladmin version 查看服務運行時長，判斷是否為 mysqld 重啟。
• 檢查錯誤日誌，尋找堆疊追蹤，可用 resolve_stack_dump 解析（注意變數值不一定 100% 準確）。

第二步：資料檔損壞的常見成因

正常情況下，write() 系統呼叫確保 SQL 執行後資料落盤，OS 保證未刷新資料寫入磁碟。啟動 --flush 可強制每條 SQL 後刷盤。損壞通常源於：

1. 更新過程中服務器/主機被強制停止。
2. mysqld 本身缺陷導致中途終止。
3. 外部程式未正確鎖表直接操作資料/索引檔。
4. 同一資料目錄運行多實例，且檔案系統鎖定失效（或用 --skip-external-locking）。
5. 資料檔包含極度損壞的資料導致 mysqld 混亂。
6. 儲存引擎層面缺陷（極罕見，可嘗試 ALTER TABLE 更換引擎驗證）。

第三步：系統化排查行動清單

1. 全表檢查：mysqladmin shutdown → myisamchk --silent --force */*.MYI → 重啟，確保乾淨狀態啟動。
2. 啟用查詢日誌：--log，約 95% 缺陷與特定查詢相關，重啟前日誌最後幾條查詢多為兇手。若能用特定查詢重現崩潰（即使表已檢查），即可提交缺陷報告。
3. 提供測試案例：最小化可重現腳本。
4. 運行官方測試套件：mysql-test 目錄與 sql-bench 基準測試，可模擬應用負載。
5. 壓力測試腳本：fork_big.pl（源碼 tests 目錄）。
6. 編譯除錯版本：--with-debug 或 --with-debug=full，獲得安全記憶體分配器與詳細輸出。
7. 套用 OS 最新補丁。
8. 嘗試 --skip-external-locking：某些系統 lockd 失效，此選項關閉外部鎖定（注意：不可同目錄雙實例，myisamchk 需謹慎）。
9. 檢查連線狀態：mysqladmin -u root processlist，即使服務假死，通常仍能連線，可見連線數與鎖定狀態。
10. 持續監控統計：mysqladmin -i 5 status 或 mysqladmin -i 5 -r status。

進階除錯：GDB 與核心傾印

• 在 GDB 中啟動 mysqld，運行測試腳本。
• 崩潰時輸出回溯與區域變數：
  backtrace → info local → up → info local → up → info local
• info threads 查看所有執行緒，切換特定執行緒分析。

其他實用策略

• 用 Perl 腳本模擬應用觸發崩潰。
• 提交詳細缺陷報告（含環境、硬體、庫版本等）。
• VARCHAR 動態行易損壞，可嘗試 ALTER TABLE ... CHAR 轉固定長度行測試（佔空間稍大但容錯性強）。
• 勿忽視硬體：記憶體與硬碟故障是隱形殺手，務必進行硬體診斷。