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 來源：簡書 簡書著做權歸做者全部，任何形式的轉載都請聯繫做者得到受權並註明出處。