壓力測試過程中，如果因為資源使用瓶頸等問題引發最直接效能問題是業務交易響應時間偏大，tps逐漸降低等。而問題定位分析通常情況下，最優先排查的是監控伺服器資源利用率，例如先用top 或者nmon等檢視cpu、記憶體使用情況，然後在排查io問題，例如網路io、磁碟io的問題。 如果是磁碟io問題，一般問題是sql語法問題、mysql引數配置問題、伺服器自身硬體瓶頸導致iops吞吐率問題。
今天主要是講解mysql 引數配置不合理導致在高併發下磁碟io問題，而mysql整體監控優化方案後面會整理《如何輕量化mysql服務效能監控》文章出來。
1、 開啟日誌跟蹤引起的磁碟io問題
例如：mysql的日誌包括錯誤日誌（errorlog），更新日誌（updatelog），二進位制日誌（binlog），查詢日誌（querylog），慢查詢日誌（slowquerylog）等，正常情況下，在生產系統或者壓力測試環境中很少有系統會時時開啟查詢日誌。因為查詢日誌開啟之後會將mysql中執行的每一條query都記錄到日誌中，會該系統帶來比較大的io負擔，而帶來的實際效益卻並不是非常大.
2、 sql寫法問題引起磁碟io高
例如：曾經在做某乙個專案時，在看到資料庫磁碟io使用率偏高，前端查詢業務交易loadrunner顯示事物響應時間偏長，通過監控工具抓取對應sql，通過計畫分析，發現該sql 中使用distinct 又多表關聯且是大表、然後使用order by，最終顯示10筆資料，而在產生中間過程資料進行篩選時，使用的是臨時表，並把資料放入臨時表中，記憶體剛好設定不大，於是放到磁碟中導致io偏高。
備註：mysql在執行sql查詢時可能會用到臨時表，臨時表儲存，mysql會先建立記憶體臨時表，但記憶體臨時表超過配置指定的值後，mysql會將記憶體臨時表匯出到磁碟臨時表；
3、 mysql引數配置問題
mysql預設配置效能低下，只能通過併發下嘗試調整引數配置來逐步優化資料庫效能，2023年底根據公司要求配合幫助某一家銀行業務系統做效能測試，因為測試環境硬體資源有限，我跟公司申請了幾台過時的筆記本，然後根據生產環境軟體版本等配置要求，進行模擬搭建效能測試環境，基礎軟體包含：mysql5.6 、centos7.2、tomcat7、 jdk1.7、redis。使用的是聯想l421 筆記本當mysql資料庫伺服器、l440當tomcat應用伺服器，壓力測試工具loadrunner、併發使用者100，壓力測試業務場景：使用者登入退出、相關票據資訊查詢、電子匯票交易流程等，在壓力測試過程中發現部分交易在50使用者併發時，資料庫磁碟i0使用率都偏高，特別是寫操作一直很高，例如測試登入退出交易，經監控資料庫磁碟io率一直偏高，如下案例分析講解：
壓力測試時，資料庫磁碟io使用率大於75%，響應時間1.6秒，通過nmon監控到的資料庫資源使用情況，如下圖一與圖二：
圖一：
圖二
資料庫伺服器資源使用率：
圖三
圖四
通過優化innndb等影響io、記憶體的一些引數後，效能問題明顯解決，優化引數內容，例如：innodb_write_io_threads、 innodb_read_io_threads、
innodb_flush_log_at_trx_commi等innodb 引擎優化io 子系統引數配置若干。
mysql資料庫高併發處理
總體思想 短,少,分流 短 1.頁面靜態化,2.使用快取 3.使用儲存過程,對於處理一次請求需要多次訪問資料庫的操作,將操作整合到儲存過程,這樣只需要一次資料庫訪問 4.延遲修改,將修改請求儲存到記憶體中,但可能會斷電丟失資料 5.使用索引 少 1.分表,但應盡量避免多表關聯查詢 2.分離活躍資料,...
mysql的i o讀取大 資料庫I O讀寫速度
工作中遇到的乙個實際問題。問題如下 長時間，大量插入資料的速度慢的問題。7 24小時的不間斷想資料庫中插入資料，單錶的插入資料量平均目前平均35條 秒。有 40多個單表表都需要插入。插入資料的同時還要對40多個單錶進行更新和查詢操作。如此頻繁的對資料庫進行操作的情況下，資料庫的速度已經不能滿足我們的...
MySQL資料庫高併發優化配置
在apache,php,mysql的體系架構中，mysql對於效能的影響最大，也是關鍵的核心部分。對於discuz 論壇程式也是如此，mysql的設定是否合理優化，直接 影響到論壇的速度和承載量！同時，mysql也是優化難度最大的乙個部分，不但需要理解一些mysql專業知識，同時還需要長時間的觀察統...