《高性能 MySQL》讀書筆記第 2 章：基準測試策略、指標、工具與實戰避坑指南

基準測試：掌握系統行為的唯一有效手段

基準測試 針對系統設計的壓力測試，目標是掌握給定負載下的系統行為、評估容量、驗證變更影響、重現問題場景。

2.1 為什麼需要基準測試？

• 唯一便捷有效的學習系統行為方法
• 觀察不同壓力下行為，評估容量上限
• 在非生產環境構造虛構場景測試
• 為應用建立單元測試套件基線

局限性：非真實流量測試，只能大致估算系統餘量。真實壓力測試構造數據極其謹慎，且不再屬於基準測試範疇。

2.2 測試策略：整體 vs 單組件

2.2.1 核心測試指標

關鍵澄清：Web 「5 萬用戶在線」≠ DB 並發。HTTP 無狀態，實際 DB 併發可能僅 10~15。測試關注 正在工作的併發線程/連接，記錄 Threads_running。

2.3 基準測試方法論

常見 11 大錯誤（必讀避坑）

1. 用真實數據子集而非全量
2. 數據分布不真實
3. 分布參數不真實
4. 多用戶場景只做單用戶測試
5. 分布式應用只在單機測試
6. 用戶行為建模不匹配
7. 反覆執行同一查詢（熱點失真）
8. 不檢查錯誤日誌（測試後必看 error log）
9. 忽略系統預熱
10. 用默認配置測試（無意義）
11. 測試時間太短

2.3.1 設計規劃原則

• 先明確問題與目標，再選標準基準或設計專用測試
• 專用測試：獲取生產快照 → 記錄代表性時間段所有查詢（開啟 General Log 或抓 HTTP 請求） → 多線程重放（每連接一線程）
• 詳細文檔化參數與結果，建立腳本庫自動化分析

2.3.2 執行時長原則

測試運行至系統穩定，穩定時長 ≥ 預熱時長。短期測試（如 60 秒）不可作性能結論，寧可參考他人長期測試結果。

2.3.3 指標採集：多收少濾

Shell 腳本全量收集原始數據（系統狀態、性能計數器、MySQL 狀態變量），事後分析過濾，避免遺漏關鍵異常點。

2.3.4 確保結果準確可復現

• 每輪測試前重置系統狀態（甚至重啟 + 預熱）
• 確保測試數據一致（快速格式化 + 分區克隆保證磁碟分布一致）
• 單變量原則：每輪只改 1~2 參數
• 異常結果勿丟棄，深挖往往有驚喜發現

2.3.5 自動化與結果分析

全流程自動化：裝載數據 → 預熱 → 執行 → 記錄 → 分析。多輪運行取中位數。腳本化分析輸出圖表。

2.3.6 繪圖的重要性

細節數據視覺化能快速發現性能拐點、抖動、瓶頸轉移等文字難以察覺的模式。

2.4 主流基準測試工具

2.5 實戰案例（書本 P52~P65，略）

2.6 總結與行動清單

1. 每位 MySQL 使用者都應掌握基準測試基礎
2. 基準測試既是解決問題工具，也是深度學習方法
3. 新手從 sysbench OLTP + FILEIO 入手
4. 建立團隊測試腳本庫：配置、採集、分析、繪圖標準化
5. 定期基準測試，建立性能基線，變更前後對比

名言：「不做基準測試的優化都是耍流氓。」—— 建立度量體系，用數據說話。