MySQL 數據庫規範--調優篇(終結篇)
前言
這篇是MySQL 數據庫規範的最後一篇--調優篇，旨在提供我們發現系統性能變弱、MySQL系統參數調優，SQL腳本出現問題的精準定位與調優方法。
目錄
1.MySQL 調優金字塔理論
2.MySQL 慢查詢分析--mysqldumpslow、pt_query_digest工具的使用(SQL腳本層面)
3.選擇合適的數據類型
4.去除無用的索引--pt_duplicate_key_checker工具的使用(索引層面)
5.反範式化設計(表結構)
6.垂直水平分表
7.MySQL 重要參數調優(系統配置)
1.MySQL 調優金字塔理論
如下圖所示：
MySQL調優金字塔理論.png
如上圖所示:
數據庫優化維度有四個:
硬件、系統配置、數據庫表結構、SQL及索引
優化成本:
硬件>系統配置>數據庫表結構>SQL及索引
優化效果:
硬件<系統配置<數據庫表結構<SQL及索引
2.MySQL 慢查詢分析
對於系統中慢查詢的分析，有助於我們更高效的定位問題，分析問題。
mysqldumpslow、pt_query_digest是進行慢查詢分析的利器。
前置條件
1.查看本機MySQL Server 慢查詢是否打開
show variables like ‘slow%‘;
慢查詢打開的情況如下所示：
慢查詢狀態
若慢查詢未打開則通過如下腳本設置慢查詢：
set global slow_query_log = on;
即
set global [上圖中選項] = [你要設置的參數值]
註意 slow_query_log_file 路徑要加單引號，因為路徑varchar 類型的。
2.1 mysqldumpslow分析慢查詢
mysqldumpslow 是MySQL自帶的分析數據庫慢查詢的原生利器，使用方法如下：
mysqldumpslow -t 3 /data/mysql/log/mysql_slow_query.log | more \G;
-t 3 顯示前3條慢查詢。
慢查詢信息及分析
慢查詢信息.png
但是 mysqldumpslow 顯示的信息比較少，比如說此條sql執行次數在整體的執行次數中占用的百分比。類似於上述信息在 mysqldumpslow 的分析結果中是不存在的。
接下裏我們介紹另一種工具 pt_query_digest
2.2 pt_query_digest分析慢查詢
之所以使用 pt_query_digest 工具對慢查詢日誌進行分析，主要原因是上述工具分析的內容更佳豐富，更加方便我們分析慢查詢。
前置條件
安裝 pt_query_digest ,Google搜索應該一大把。
確保 pt_query_digest 安裝成功 執行如下操作：
pt-query-digest /data/mysql/log/mysql_slow_query.log > slow_log.report
上述命令表示分析本機慢查詢，並輸出報表(文件)
接下來分析生成的報表：
tail slow_log.report
按如下圖所示信息：
pt_query_digest報表分析.png
我們對以上紅色框圖標記的報表信息進行詳細描述，事實上這也是我們需要掌握的重點：
1.pct :sql語句某執行屬性占所有慢查詢語句某執行屬性的百分比
1.total：sql語句某執行屬性的所有屬性時間。
2.Count：sql語句執行的次數，對應的pct 表示此sql 語句執行次數占所有慢查詢語句執行次數的％比。上圖為25%，total:表示總共執行了1次。
3.Exec time:sql執行時間
4.Lock time:sql執行期間被鎖定的時間
5.Rows sent:傳輸的有效數據，在select 查詢語句中才有值
6.Rows examine:總共查詢的數據，非目標數據。
7.Query_time distribution:查詢時間分布
8.SQL 語句:上圖中為 select * from payment limit 10\G;
舉例說明：加入某執行次數(count) 占比較高的sql語句，執行時間很長，Rows sent 數值很小，Rows examine 數值很大則表明(I/O較大)。那就表明有可能 sql 查詢語句走了全表掃描，或者全索引掃描。那麽就要建立合適索引或者優化sql語句了。
如下很好的展示了我們在分析慢查詢時需要著重分析的三點：
慢查詢分析的三個基準點.png
3.選擇合適的數據類型
可以參考MySQL開發規範--設計篇中的1.6 數據表設計與規劃
如下圖是常用字段類型的選擇建議：
選擇合適的數據類型
4.去除無用的索引--pt_duplicate_key_checker工具的使用(索引層面)
此工具可以分析選定的 database 中的所有表中建立的index 中可能重復的索引，並給出了刪除建議。
5.反範式化設計(表結構)
關於範式的理解，請參考--MySQL 數據庫規範--設計篇1.1 數據庫表的設計範式(三範式&反範式)
先看一個不滿足第三範式的數據表設計：
不滿足第三範式的數據表設計.png
不滿足第三範式產生的問題：
假如將表中屬於飲料分類的數據全部刪除了，那麽飲料分類也就不存在了，飲料的分類描述也就沒了，查詢不到了。這明顯是不合理的。
重點：滿足第三範式要求非鍵屬性之間沒有任何依賴關系，上圖中分類與分類描述存在直接依賴關系。所以不符合第三範式的要求，那麽要讓表符合第三範式需要怎樣做呢？
拆分後滿足第三範式的表：
滿足第三範式的表.png
我們采用一張 分類--商品名稱 中間表來充當分表之後的中間橋梁。
當然如果一直遵循範式化設計，什麽設計都向第三範式靠攏，當查詢需要連接很多表的時候，建立索引已經起不到什麽作用了，因為字段都不在同一張表中，所以建立索引是無用功，那麽就要考慮反範式化的設計了。
6.垂直、水平分表
原則上當表中數據記錄的數量超過3000萬條，再好的索引也已經不能提高數據查詢的速度了，這時候就需要將表拆分成更多的小表，來進行查詢。
分表的機制有兩種:
垂直分表:也就是將一部分列割裂開將數據放置在新設置的表中，優先選擇字段值長度較長，類型較重的字段進行垂直分離。
水平分表:將表中數據水平切分，可以按照範圍、取模運算、hash運算進行數據切割，每張表的結構信息都是一樣的。
7.MySQL 重要參數調優(系統配置)
7.1 操作系統配置優化
操作系統配置優化
打開操作系統文件限制.png
簡要介紹一下：
1.tcp連接配置，超時時間配置
2.linux上文件打開數量限制
3.除此之外，最好在MySQL 服務器上關閉iptables,selinux 等防火墻軟件。
7. 2 MySQL 配置文件優化
MySQL 可以通過啟動時制定配置參數和使用配置文件兩種方法進行配置，在大多數情況下配置文件位於/etc/my.cnf或是/etc/mysql/my.cnf MySQL查找配置文件順序可以通過以下方法獲得：
$ /usr/sbin/mysqld --verbose --help | grep -A 1 ‘Default options‘
註意:如果多個位置存在配置文件，後面的會覆蓋前面的
7.2.1 innodb_buffer_pool_size
innodb_buffer_pool_size 是非常重要的一個參數，用戶配置Innodb 的緩沖池大小。如果數據庫中只有Innodb表，則推薦配置量為總內存的75%。
一般情況下運行如下命令，即可獲得配置innodb_buffer_pool_size 參數的最佳值：
select engine round(sum(data_length+index_length)/1024/1024,1) as
‘total MB‘ from information_schema.tables where table_schema not in ("information_schema","performance_schema") group by engine;
Innodb_buffer_pool_size > Total MB;
7.2.2 innodb_buffer_pool_instance
MySQL 系統中有一些資源是需要獨占使用的，比如緩沖去就是這樣一種資源,因此如果系統中只有一個緩沖池，那麽會增加阻塞的幾率。我們多分成多個，則可以增加並發性能。
7.2.3 innodb_log_buffer_size
innodb log緩沖的大小，設置大小只能能容得下1s中產生的事務日誌就可以。
7.2.4 innodb_flush_log_at_trx_commit
關鍵參數，對innodb 的I/O影響很大。默認值為1，可以去0，1，2三個值，一般建議為2，但如果數據安全性要求較高則默認使用1。
- 0:每隔1s中才將事務提交的變更記錄刷新到磁盤
- 1:每一次事務提交都把變更日誌刷新到磁盤（最安全的方式）
- 2:每一次提交將日誌刷新到緩沖區，隔1s之後會將日誌刷新到磁盤。
7.2.5 innodb_read_io_threads && innodb_write_io_threads
這兩個參數決定了Innodb讀寫的I/O進程數，默認為4。
決定這兩個參數數值的因素也有兩個：cpu核數、應用場景中讀寫事務比例。
7.2.6 innodb_file_per_table
關鍵參數，默認情況下配置為off。
控制innodb每一個表使用獨立的表空間，默認情況下，所有的表都會建立在共享表空間當中。
使用共享表空間會帶來什麽問題：
1.多個表對共享表空間的操作，是順序進行的，這樣的話操作效率在並發情況下回降低。
2.如果現在要刪除一張表，會導致共享表空間先要將數據導出來，再重組。
7.2.7 innodb_stats_on_metadata
作用：決定了MySQL在什麽情況下會刷新innodb表的統計信息。
保證數據庫優化器能使用到最新的索引，但不能太頻繁，一般設置為off。
作者：fxliutao
鏈接：https://www.jianshu.com/p/55020afb5eba
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯系作者獲得授權並註明出處。
MySQL 數據庫規範--調優篇(終結篇)