工具要動手實踐，形成自己的判斷標準。面試時能說出「關注哪些指標、為什麼關注、閾值多少、如何優化」才算專業。
| 工具 | 類別 | 核心用途 |
|---|---|---|
| vmstat / iostat / mpstat / ifstat / dstat | 系統統計 | CPU、內存、I/O、網絡、分頁全維度觀測 |
| pstack | 進程棧 | 定位進程掛起/死循環的函數棧（需 root/屬主） |
| sysbench | 壓測 | 文件 I/O、CPU、內存、OLTP 基準測試，模擬生產負載 |
| tcprstat | TCP 分析 | 被動抓包統計請求響應時間分佈（P50/P95/P99） |
| tcpdump | 抓包 | 抓取 MySQL 協議包，分析慢查詢網絡往返、錯誤包 |
| perf | 性能剖析 | 內核級熱點函數、指令級分析（2.6.31+） |
| pt-stalk | 診斷採集 | 觸發條件時自動採集 GLOBAL STATUS、PROCESSLIST、InnoDB 狀態等 |
| orzdba | 實時監控 | Perl 腳本，Linux + MySQL 關鍵指標實時儀表板 |
# 間隔 2 秒，採樣 3 次
vmstat 2 3
關鍵欄位：
r：運行隊列進程數，持續 > CPU 核心數說明 CPU 飽和。b：不可中斷睡眠進程（通常等 I/O），持續 > 0 表示 I/O 瓶頸。swpd/free/buff/cache：內存使用細分。si/so：swap in/out，**持續非 0 表示內存嚴重不足**。bi/bo：塊設備讀/寫扇區數，**bo 持續高寫入壓力大**。in/cs：中斷數/上下文切換數，cs 高說明線程切換頻繁。us/sy/id/wa/st：用戶/系統/空閒/等待I/O/偷取 CPU 百分比，**wa 高 = I/O 瓶頸**。
# 準備 10G 測試文件
sysbench --test=fileio --file-total-size=10G prepare
# 隨機讀寫壓測 1 小時
sysbench --test=fileio --file-total-size=10G --file-test-mode=rndrw --max-time=3600 --max-requests=0 run
# 清理
sysbench --test=fileio --file-total-size=10G cleanup
# 監聽 3306 端口，每 1 秒輸出統計
tcprstat -p 3306 -t 1 -n 0
# 輸出含：count, min, max, avg, p50, p95, p99, stddev
**優勢**：無需修改應用代碼，旁路部署即可獲取真實客戶端視角的響應時間分佈。
# 當 Threads_running > 100 時觸發採集，持續 30 秒，間隔 1 秒
pt-stalk --function=status --variable=Threads_running --threshold=100 --cycles=30 --interval=1 --dest=/var/log/pt-stalk
生成的文件包含：SHOW GLOBAL STATUS、SHOW PROCESSLIST、SHOW ENGINE INNODB STATUS、vmstat、iostat、mpstat 等，**事後複盤神器**。
perl orzdba.pl --host=127.0.0.1 --user=root --password=xxx --interval=1
終端實時滾動顯示：QPS、TPS、緩存命中率、InnoDB 行鎖、IOPS、網絡流量、慢查詢數等，**無需部署 Prometheus/Grafana 即可獲得生產級可觀測性**。
一句話總結： 這 8 把「刀」配合基線 + 告警 + 複盤流程，足以應對 95% 的 MySQL 性能故障現場。
