MYSQL服務器中單個CPU佔用過高問題的定位與解決

一次對某查詢交易性能測試執行過程中，通過nmon監控指標發現MySQL數據庫服務器的某個CPU的佔用一直是99%左右。

本次數據庫的資源配置爲4C8G，另外三個CPU的使用率爲0，對於MySQL單核CPU佔用過高問題進行了分析調優過程。

01

確認io_thread的參數設置，通過執行：

show variables like 'innodb_read_io_threads';

（左右滑動查看完整代碼）

show variables like 'innodb_write_io_threads';

（左右滑動查看完整代碼）

查詢出read和write的thread設置都是8，因此筆者認爲這並不是CPU佔用過高的根本原因。

02

通過pidstat -upidstat來判斷是否利用到多核CPU，確認MySQL是可以利用到多核CPU。

通過以上排查，可以看出MySQL數據庫本身的設置不是造成單核cpu過高的問題，那麼是不是查詢語句的問題呢？

03

檢查sql語句的執行情況以及數據庫是否存在鎖的問題，我們可以用到MySQL提供的information_schema來進行性能的故障排除。

innodb_trx表是MySQL提供的information_schema中的一張表，INNODB_TRX 表提供有關當前在innodb內部的每個事務的信息，包括事務是否正在等待鎖、事務何時開始以及事務正在執行的SQL語句，必須有procrss特權才能查詢該表。

04

通過 SELECT * FROM information_schema.INNODB_TRX來檢查系統是否有反覆執行的交易，特別注意的是nnodb_trx這張表，它不是一張歷史記錄表，而是隻記錄當前正在執行中的事務，所以要在執行過程中進行跟蹤。

在服務器中查到有若干sql語句處於running狀態，藉助MySQL慢查詢日誌來逐一排查正在執行的sql語句。

long_query_time

MySQL的慢查詢，全名是慢查詢日誌，是MySQL提供的一種日誌記錄，用來記錄在MySQL中響應時間超過閾值的語句具體環境中，運行時間超過long_query_time值的SQL語句，則會被記錄到慢查詢日誌中。

long_query_time的默認值爲10，默認情況下，MySQL數據庫並不啓動慢查詢日誌，需要手動來設置這個參數。

set global slow_query_log=1可以開啓慢查詢日誌，但是隻對當前數據庫生效，MySQL重啓後則會失效。如下：

 mysql> show variables  like '%slow_query_log%'; +---------------------+-----------------------------------------------+ | Variable_name       | Value                                          +---------------------+-----------------------------------------------+ | slow_query_log      | OFF                                            | slow_query_log_file | /home/WDPM/MysqlData/mysql/DB-Server-slow.log  +---------------------+-----------------------------------------------+ 2 rows in set (0.00 sec) mysql> set global slow_query_log=1;

（左右滑動查看完整代碼）

global long_query_time

通過mysql> set global long_query_time=2;來設置超過該運行時間（s）的sql會被記錄，我們設置了查詢超過2秒就會被記錄。

Slow_queries

可以使用Slow_queries系統變量。查詢有多少條慢查詢記錄。

設置慢查詢日誌存放的位置

mysql> set global slow_query_log_file='/usr/local/mysql/data/slow.log';

（左右滑動查看完整代碼）

mysqldumpslow工具

MySQL提供了日誌分析工具mysqldumpslow，可以分析sql語句的數量等情況，根據自己的需要。

比如，得到返回記錄集最多的5個SQL：

mysqldumpslow -s r -t 5 /database/mysql/mysql06_slow.log

（左右滑動查看完整代碼）

得到訪問次數最多的5個SQL：

mysqldumpslow -s c -t 5 /database/mysql/mysql06_slow.log

（左右滑動查看完整代碼）

通過藉助慢查詢日誌，我們發現有6條sql的執行記錄運行時間很長，甚至存在140000秒的記錄。

通過開發測試人員的分析，發現有部分數據表未設置索引，有的雖然設置了主鍵索引，但是忽略了where條件裏的字段並未設置索引，導致查詢時間過長。

發現上述問題後，開發人員更新設置索引情況，同時將查詢熱表的sql語句按時間區間進行優化，再次執行性能測試並監控，發現CPU的性能分佈均勻在4核，平均cpu的使用率爲35%，sql的執行時間也大大縮減。

以上就是我在MYSQL性能測試及調優過程的經驗。

End

Have Fun ~ Tester ！

• FunTester測試框架架構圖初探
• 10萬QPS，K6、Gatling和FunTester終極對決！
• 環境基礎【FunTester框架教程】
• 生產環境中進行自動化測試
• 小白自動化測試指南
• 成爲自動化測試的7種技能
• Selenium4前線快報
• 測試爲何會錯過Bug
• httpclient使用HTTP代理實踐
• Socket.IO接口多用戶測試實踐
• 無數據驅動自動化測試
• 從Java到Groovy的八級進化論
• Selenium 4以後，再不相見的API

點擊閱讀閱文，查看FunTester歷史原創集合

- END -

戳 “閱讀原文”一起來充電吧!

本文分享自微信公衆號 - FunTester（NuclearTester）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。