mysql性能監(jiān)控是運維調(diào)優(yōu)的基礎(chǔ)環(huán)節(jié)，必須依賴數(shù)據(jù)而非經(jīng)驗。常用工具分為命令行類（如top/htop、iostat、vmstat、show status、show processlist）和圖形化系統(tǒng)（如prometheus+grafana、zabbix、pmm、mem）。應(yīng)重點關(guān)注連接數(shù)、qps、tps、慢查詢數(shù)、innodb緩沖池命中率、臨時表創(chuàng)建次數(shù)、鎖等待與死鎖等指標。告警應(yīng)基于歷史數(shù)據(jù)設(shè)定閾值，優(yōu)先關(guān)注關(guān)鍵問題，避免“告警疲勞”。監(jiān)控數(shù)據(jù)建議保留60~90天，兼顧排障與趨勢分析。
mysql的性能監(jiān)控不是可有可無的事，而是運維和調(diào)優(yōu)中非常基礎(chǔ)的一環(huán)。光靠經(jīng)驗判斷不夠，得看數(shù)據(jù)說話。常用的做法是用一些工具收集指標、分析趨勢，找出瓶頸所在。本文就聊聊幾個常用的監(jiān)控工具以及你該關(guān)注哪些關(guān)鍵指標。
1. 常用MySQL性能監(jiān)控工具有哪些？
目前市面上主流的MySQL監(jiān)控工具大致可以分為兩類：命令行類工具 和 可視化監(jiān)控系統(tǒng)。
-
命令行工具：
- top / htop：查看服務(wù)器整體CPU和內(nèi)存使用情況。
- iostat：用于監(jiān)控磁盤IO性能。
- vmstat：可以查看虛擬內(nèi)存、進程、中斷等信息。
- SHOW STATUS 和 SHOW PROCESSLIST：這是MySQL內(nèi)置命令，用來快速查看當前數(shù)據(jù)庫狀態(tài)和正在執(zhí)行的SQL線程。
-
圖形化監(jiān)控系統(tǒng)：
- Prometheus + Grafana：組合使用，靈活度高，適合自建監(jiān)控體系。
- Zabbix：功能全面，支持自動發(fā)現(xiàn)、告警機制，適合有一定規(guī)模的環(huán)境。
- Percona Monitoring and Management (PMM)：專為MySQL設(shè)計的開源監(jiān)控平臺，集成了Prometheus和Grafana，開箱即用。
- MySQL Enterprise Monitor（MEM）：官方商業(yè)產(chǎn)品，提供深度監(jiān)控和預(yù)警功能。
如果你只是想快速上手，PMM是個不錯的選擇；如果已經(jīng)有一套運維體系，那用Prometheus+Grafana更靈活。
2. MySQL監(jiān)控應(yīng)該重點關(guān)注哪些指標？
監(jiān)控工具裝好了，但不知道看什么等于白搭。下面這些指標是你日常排查問題時最常需要關(guān)注的：
-
連接數(shù)（Threads_connected）
- 過高的連接數(shù)可能意味著連接池配置不合理，或者有慢查詢阻塞了連接釋放。
-
QPS（Queries per second）與TPS（Transactions per second）
- QPS表示每秒處理的查詢數(shù)量，TPS是事務(wù)處理量。這兩個值波動大可能說明業(yè)務(wù)負載變化或存在異常SQL。
-
慢查詢數(shù)量（Slow_queries）
- 慢查詢是拖累性能的常見原因。建議開啟慢查詢?nèi)罩荆⒍ㄆ诜治觥?/li>
-
InnoDB緩沖池命中率（InnoDB Buffer Pool Hit Ratio）
- 如果命中率低于95%，說明緩存不夠用，可能需要增加innodb_buffer_pool_size配置。
-
臨時表創(chuàng)建次數(shù)（Created_tmp_tables）
- 大量臨時表會影響性能，尤其是當它們被創(chuàng)建在磁盤上時（查看Created_tmp_disk_tables）。
-
鎖等待與死鎖（Table_locks_waited、InnoDB_row_lock_waits）
- 高并發(fā)下鎖競爭激烈會導(dǎo)致性能下降甚至服務(wù)不可用。
這些指標最好結(jié)合時間序列來看，單點數(shù)值意義不大。比如某個時刻QPS突然飆升，同時慢查詢數(shù)也上升，那就要查當時執(zhí)行的SQL有沒有問題。
3. 如何設(shè)置告警？別等到出事才反應(yīng)
監(jiān)控的目的不只是“看看”，更重要的是提前發(fā)現(xiàn)問題。你可以根據(jù)歷史數(shù)據(jù)設(shè)定閾值，一旦超過就觸發(fā)告警。
常見的告警場景包括：
- 連接數(shù)超過最大允許連接的80%
- 每分鐘慢查詢數(shù)量超過一定數(shù)量
- 緩沖池命中率持續(xù)低于90%
- 主從延遲超過指定秒數(shù)（Seconds_Behind_Master）
不同的監(jiān)控系統(tǒng)設(shè)置方式略有不同，但基本邏輯是一樣的：選擇指標 → 設(shè)置閾值 → 觸發(fā)通知方式（郵件、釘釘、企業(yè)微信等）。
建議不要一開始就設(shè)置太多告警，容易造成“告警疲勞”。先挑幾個最關(guān)鍵、最容易出問題的來監(jiān)控，穩(wěn)定后再逐步擴展。
4. 監(jiān)控數(shù)據(jù)保存多久合適？
監(jiān)控數(shù)據(jù)保留周期也是一個容易忽略的問題。短期數(shù)據(jù)（如最近7天）用于實時排障沒問題，但如果要做長期趨勢分析，至少要保留幾個月的數(shù)據(jù)。
- PMM默認保留30天左右的數(shù)據(jù)，可以通過調(diào)整Prometheus配置延長。
- Zabbix 可以對接外部存儲（如MySQL、TimescaleDB），實現(xiàn)長期存儲。
- 自建系統(tǒng)可以根據(jù)需求定制保留策略。
一般來說，保留60~90天是一個比較合理的平衡點，既能滿足排障需求，又不至于占用太多資源。
基本上就這些內(nèi)容了。監(jiān)控工具選對、指標看得準、告警設(shè)得合理，MySQL的運行狀態(tài)就能掌握在自己手里，出了問題也不至于手忙腳亂。
