前言

這篇是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.選擇合適的資料型別

如下圖是常用欄位型別的選擇建議：

選擇合適的資料型別

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。