共計 1877 個字符，預計需要花費 5 分鐘才能閱讀完成。
如何解析 MySQL 性能瓶頸排查定位，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。
導讀
從一個現場說起，全程解析如何定位性能瓶頸。
排查過程
收到線上某業務后端的 MySQL 實例負載比較高的告警信息，于是登入服務器檢查確認。
1. 首先我們進行 OS 層面的檢查確認
登入服務器后，我們的目的是首先要確認當前到底是哪些進程引起的負載高，以及這些進程卡在什么地方，瓶頸是什么。
通常來說，服務器上最容易成為瓶頸的是磁盤 I / O 子系統，因為它的讀寫速度通常是最慢的。即便是現在的 PCIe SSD，其隨機 I / O 讀寫速度也是不如內存來得快。當然了，引起磁盤 I / O 慢得原因也有多種，需要確認哪種引起的。
第一步，我們一般先看整體負載如何，負載高的話，肯定所有的進程跑起來都慢。
可以執行指令
某些進程 / 服務消耗更多 CPU 資源（服務響應更多請求或存在某些應用瓶頸）；
發生比較嚴重的 swap（可用物理內存不足）；
發生比較嚴重的中斷（因為 SSD 或網絡的原因發生中斷）；
磁盤 I / O 比較慢（會導致 CPU 一直等待磁盤 I / O 請求）；
這時我們可以執行下面的命令來判斷到底瓶頸在哪個子系統（橫版查看）：
[yejr@imysql.com:~ ]# top
top - 11:53:04 up 702 days, 56 min, 1 user, load average: 7.18, 6.70, 6.47
Tasks: 576 total, 1 running, 575 sleeping, 0 stopped, 0 zombie
Cpu(s): 7.7%us, 3.4%sy, 0.0%ni, 77.6%id, 11.0%wa, 0.0%hi, 0.3%si, 0.0%st
Mem: 49374024k total, 32018844k used, 17355180k free, 115416k buffers
Swap: 16777208k total, 117612k used, 16659596k free, 5689020k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
14165 mysql 20 0 8822m 3.1g 4672 S 162.3 6.6 89839:59 mysqld
40610 mysql 20 0 25.6g 14g 8336 S 121.7 31.5 282809:08 mysqld
49023 mysql 20 0 16.9g 5.1g 4772 S 4.6 10.8 34940:09 mysqld
很明顯是前面兩個 mysqld 進程導致整體負載較高。
而且，從 Cpu(s) 這行的統計結果也能看的出來，%us
一次請求讀寫的數據量太大，導致磁盤 I / O 讀寫值較大，例如一個 SQL 里要讀取或更新幾萬行數據甚至更多，這種最好是想辦法減少一次讀寫的數據量；
SQL 查詢中沒有適當的索引可以用來完成條件過濾、排序（ORDER BY）、分組（GROUP BY）、數據聚合（MIN/MAX/COUNT/AVG 等），添加索引或者進行 SQL 改寫吧；
瞬間突發有大量請求，這種一般只要能扛過峰值就好，保險起見還是要適當提高服務器的配置，萬一峰值抗不過去就可能發生雪崩效應；
因為某些定時任務引起的負載升高，比如做數據統計分析和備份，這種對 CPU、內存、磁盤 I / O 消耗都很大，最好放在獨立的 slave 服務器上執行；
服務器自身的節能策略發現負載較低時會讓 CPU 降頻，當發現負載升高時再自動升頻，但通常不是那么及時，結果導致 CPU 性能不足，抗不過突發的請求；
使用 raid 卡的時候，通常配備 BBU（cache 模塊的備用電池），早期一般采用鋰電池技術，需要定期充放電（DELL 服務器 90 天一次，IBM 是 30 天），我們可以通過監控在下一次充放電的時間前在業務低谷時提前對其進行放電，不過新一代服務器大多采用電容式電池，也就不存在這個問題了。
文件系統采用 ext4 甚至 ext3，而不是 xfs，在高 I / O 壓力時，很可能導致 %util 已經跑到 100% 了，但 iops 卻無法再提升，換成 xfs 一般可獲得大幅提升；
內核的 io scheduler 策略采用 cfq 而非 deadline 或 noop，可以在線直接調整，也可獲得大幅提升。
關于如何解析 MySQL 性能瓶頸排查定位問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注丸趣 TV 行業資訊頻道了解更多相關知識。
