環境介紹
硬件配置
| cpu核心數 | 內存大小 | 磁盤空間 |
|---|---|---|
| 16核 | 256G | 3T |
軟件環境
| 操作系統版本 | mysql版本 | 表數目 | 單表行數 |
|---|---|---|---|
| centos-7.4 | mysql-5.7.22 | 128張表 | 2kw行 |
優化層級與指導思想
優化層級
MySQL數據庫優化可以在多個不同的層級進行，層級的常見分法有1):SQL優化 2):參數優化 3):架構優化；本文重點關注第2層，並通過一次完整的優化案例來講解參數優化的內在邏輯。
指導思想
1、日志先行 -- 一個事務能否成功提交的關鍵是與它相關的日志是否成功落盤，與數據沒有太大的關系；也就是說對寫的優化可以表述為各方面的資源向寫操作傾斜。
2、瓶頸分析 -- 通過show global status 的各個計數器的值基本上就能分析出當前瓶頸所在，再結合一些簡單的系統層面的監控工具如top iostat 等通常就能明確瓶頸。
3、整體性能是“讀”&“寫”之間的再平衡。
優化過程
最小化安裝情況下的性能表現
my.cnf中的內容
圖像地址： http://www.sqlpy.com/mysqlz/tuninglog/result/cm16c256g4096ssd/0/
監控數據
分析&優化思路
對監控數據有兩種可能的解釋：1): 由於最小化的安裝的buffer_pool_size比較小，所以會頻繁的觸發innodb_buffer_pool的最大臟頁的限制，使得innodb進入爆力刷盤的模式，這種情況下io使用率會明顯上升。2): redo日志重用。 最終的影響可能是兩者的疊加，這里先從buffer_pool開始優化。
優化innodb_buffer_pool_size
my.cnf中的內容
圖像地址：http://www.sqlpy.com/mysqlz/tuninglog/result/cm16c256g4096ssd/1/
監控數據
調整innodb_buffer_pool_size前后的性能對比 
性能大概提高3倍 圖像地址：http://www.sqlpy.com/mysqlz/tuninglog/compare/cm16c256g4096ssd/0/1/
分析&優化思路
1、針對innob_buffer_pool_size的調整取得了一定的收獲，下面將要調整的就是針對redo重用的情況了，也就是說我們要增大innodb_log_files_in_group和innodb_log_file_size到一個合適的值。
2、innob_buffer_pool_size的調整取得了一定的收獲還可以更進一步，那就是增大innodb_buffer_pool_instances的值。
優化innodb_log_files_in_group&innodb_log_file_size
根據對之前測試的記錄每完成一組測試LSN增大4.5G、持續時間大概是5分鍾；理論上把redo文件增大到5G可以做到整個測試的過程中不發生日志重用、這樣的話測試的跑分會更高，不過這個會影響數據庫宕機恢復的時間。MySQL在默認配置下innodb_log_files_in_group=2，innodb_log_file_size=48M也就是說跑完一組測試redo日志要刷新48輪(1024*4.5/96 ==48) 先看一下把日志刷新調整到9輪的情況。
my.cnf中的內容
圖像地址：http://www.sqlpy.com/mysqlz/tuninglog/result/cm16c256g4096ssd/2/
調整innodb_log_files_in_group&innodb_log_file_size前后的性能對比 
性能大概提高2倍 圖像地址：http://www.sqlpy.com/mysqlz/tuninglog/compare/cm16c256g4096ssd/1/2/
現在看一下日志重用控制在一輪(5G)之內的性能表現
my.cnf中的內容
調整innodb_log_files_in_group&innodb_log_file_size前后的性能對比 
性能大概提高2倍圖像地址：http://www.sqlpy.com/mysqlz/tuninglog/compare/cm16c256g4096ssd/2/3/
分析&優化思路
1、增大redo到5G的情況下由於整個測試過程中幾乎沒有日志文件重用的問題，這樣也就規避由些引發的大量數據刷盤行為，所以性能曲線也就更平滑了。
2、通過show global status 發現Table_open_cache_overflows=200W+、Thread_created=2k+
3、%Cpus : 80.5 us, 13.8 sy, 0.0 ni, 5.4 id, 0.0 wa, 0.0 hi, 0.3 si, 0.0 st 95%的使用率cpu資源成了大問題，這個使用率下能調整的參數不多了
3、對磁盤的監控數據表明util的峰值已經下降到14%、磁盤已經不在是問題；所以針對innodb_buffer_pool_size、innodb_log_files_in_group&innodb_log_file_size 這兩次優化的進入一步優化innodb_buffer_pool_instances、innodb_log_buffer_size 先不進行；在些采用“抓大放小”的方式先調整表緩存。
優化table_open_cache&table_open_cache_instances&innodb_sync_spin_loops&thread_cache_size
由於cpu使用率達到了95%看到這個數值有一種發自內心的無力感，所以打算所目前status中能明確的一些問題直接一起調整了；增大table_open_cache&table_open_cache_instances用於優化表緩存、增大thread_cache_size使用cpu不用頻繁的創建消毀線程、增大innodb_sync_spin_loops是希望盡可能的避免上下文切換(由於目前的監控粒度不是特別細所以無法給出13.8%中有多少是上下文切換)也就是說增大innodb_sync_spin_loops更多的是出於職業判斷
my.cnf中的內容
調整前后的比較 
總結
考慮到cpu使用率已經達到95%且增加物理cpu不現實的情況下，決定MySQL參數優化到些為止了；最后來看一眼這次優化成果。 
作者：
作者： 蔣樂興
時間： 2018-05-08
個人網站： www.sqlpy.com