葉金榮：MySQL通用優化技巧

轉自：http://mp.weixin.qq.com/s?__biz=MjM5NDE0MjI4MA==&mid=208777870&idx=1&sn=6efddd6283e4deb3fe55a141b0db965c

本文根據 DevOps華南運維圈@UCloud微信羣的「運維在線」欄目的嘉賓分享整理而成。「運維在線」將邀請業界運維前線技術專家做爲分享嘉賓，分享技術趨勢和技術實戰，爲運維朋友提供各類踩坑、躲坑、繞坑新技能。

嘉賓介紹

葉金榮
Oracle MySQL ACE，國內最先的MySQL推廣者。2006年創辦國內首個MySQL專業技術網站 MySQL 中文網。資深MySQL專家，10餘年MySQL經驗，擅長MysQL性能優化、架構設計、故障排查。

內容提綱

1. MySQL的特色；

2. 硬件、系統優化；

3. MySQL 配置優化；

4. SCHEMA設計優化；

5. SQL 優化；

6. 其餘優化。

MySQL 的特色

首先，須要明確的是。想要作好MySQL優化，須要先了解MySQL都有哪些特色：

簡言之，MySQL通常用於互聯網業務的數據持久化存儲，而且用於保證數據的一致性、可靠性，而不是用於：

• 複雜查詢；

• 複雜運算；

• 大二進制存儲。

等奇葩用途。

CPU的利用特色

看看MySQL不一樣版本對CPU多核的支持、利用狀況：

建議：

• 採用最新MySQL版本，以提高其CPU利用率；

• 每一個SQL足夠簡單，不要太過複雜；

• 每一個鏈接足夠快速完成，不要「戀戰」。

內存利用特色

內存利用、管理方面有什麼特色呢？

建議：

• 關閉query cache；

• 採用InnoDB；

• 採用Percona\MariaDB分支版本；

• 簡單KV數據用NOSQL存儲，不使用MySQL。

磁盤的利用特色

最後看下磁盤I/O方面的特色：

建議：

• 使用多盤提高總體I/O性能；

• 多使用高速I/O設備；

• 儘可能加大內存，緩解I/O負載。

MySQL 優化

瞭解完MySQL各方面的特色後，咱們能夠開始進行優化工做了。

在開始以前，咱們須要先明確幾點：

1. 爲什麼而優化？領導指派\用戶投訴\監控預警\沒事找事？當前跑得好好的話，就不必折騰神馬優化沒事找抽，即使想練手，也要悠着點，防止誤操做；

2. 優化的目標是什麼，說白了，就是要解決什麼瓶頸，切忌在過程當中偏離初心；

3. 計算投入產出比，好比爲了讓性能提高1%而投入1人月，基本上是很是不划算了，還不如去幹點別的；

4. 優化前作好現場信息採集，優化後再次採集作對比，確認優化成果（用來邀功啊，讓老闆看到你的成績，年末加加薪什麼的，最起碼也能鍛鍊總結概括文檔能力吧）。

一般，咱們進行MySQL優化工做的套路是這樣的：

確認需求，先明確當前的運行狀態，是否真的須要進行優化，別沒事找事；

常見瓶頸：

• 絕大多數瓶頸在於I/O子系統；

• 若CPU很高，90%以上是由於索引不當；

• 發生swap時，可能由於內存分配過小或過大；

• iowait過高時，想辦法從索引角度入手優化，以及提升I/O設備性能，增長內存，減小排序，減小SELECT一次性讀取數據量。

經常使用優化策略

1. 瞬間併發很高，採用thread pool；

2. 頻繁order by\group by，索引入手；

3. 適當調整內存，不要太大或過小。通常ibp設置爲50% ~ 70%爲宜；

4. iowait高，加內存，提升iops，減小數據讀寫。

制定方案時，重點解決發生頻率高的問題（量變動容易引發質變）；回顧反饋，整理文檔，回顧總結，從零散資料中總結出規律，預防風險再次出現。

通常採用下面幾個瓶頸分析工具：

絕大多數狀況下，有經驗的工程師靠sysstat工具集中的就足夠了，不少問題一看現象大概就能知道瓶頸何在。

在MySQL層面，有哪些確認瓶頸的手段呢？

硬件、系統優化

咱們繼續MySQL優化之旅。先來看看從硬件以及OS層面，都有哪些能夠優化的。首先主要是BIOS中關於CPU和內存的參數調整，其次是RAID方面的優化。

再來看看幾個參考配置圖：

一、CPU選擇最大性能模式，避免節能模式致使性能不足。

二、關閉NUMA，下降swap機率。

三、採用RAID-10，而且選擇FORCE WB。

在OS層面，能夠有幾個優化手段：

• 調整IO Scheduler

• 使用XFS

• 調整其餘內核選項備

備註：

1. vm.swappiness，下降發生swap的概率；

2. vm.dirty_background_ratio & vm.dirty_ratio，避免瞬間大量I/O請求致使系統卡死。

從這個壓測結果能夠看到noop/deadline有明顯優點。

這個io scheduler還能夠在線修改的哦，還等神馬？

echo deadline > /sys/block/sdc/queue/scheduler

在用PCIe SSD設備作測試時，XFS的IOPS能跑到ext4的4倍，表現很是好。

還有什麼理由不用XFS呢？

xfs掛載參數：

/dev/sdc1 /data xfs defaults,noatime,nodiratime,nobarrier 0 0

格式化參數不用特別指定，默認的便可。

MySQL配置優化

前面講到，給MySQL分配的內存不要太大或過小，那麼多少合適呢。

首先，要搞清楚MySQL的內存都由哪些部分組成：

1. global buffers和oracle的SGA一個意思，就是全局一次分配，多個線程間共享。

2. thread buffers和oracle的PGA一個意思，每一個線程單獨分配，線程間不能相互共享，所以不要分配過大，避免內存不夠使用，發生OOM。

原則： 對這些選項調整時，不要照貓畫虎隨便調整，要先作到內心有數，瞭解其具體做用才動手。

看看innodb_flush_log_at_trx_commit分別爲0、一、2的性能對好比：

若是再啓用binlog後的對比：

最後，再加上sync_binlog選項不一樣設置的對比：

備註： 這3個測試結果圖均來自Percona。

結論&建議：

1. 想要保證數據安全，就設置 trx_commit =1 & sync_binlog = 1

2. 在slave上或非關鍵場景，能夠都改爲0

SCHEMA設計優化

接下來看看MySQL的模式（SCHEMA）設計優化要點：

要點：

1. 默認地，使用InnoDB引擎，別上MyISAM給本身找事；

2. InnoDB必需要有自增（或相似自增）屬性的主鍵；

3. 不使用或少使用TEXT/BLOB列；

4. NOT NULL主要是爲了優化索引效率；

5. 若無特殊需求，都可使用latin1字符集，不然用utf8\utf8mb4等大字符集保證通用性。

其餘要點：

SQL優化

SQL優化層面有幾個要點：

以及 COUNT(*)、大分頁 的優化要點：

接下來，咱們來看看EXPLAIN的結果中，有哪些關鍵信息要注意的。首先看下EXPLAIN結果的type列，均可以給咱們什麼信息：

再看看Extra列有哪些狀態要引發重視：

MySQL的慢日誌可用下面的工具來進行解析和管理：

pt-query-digest + Box Anemometer的案例，能夠對slow log進行便捷管理。

關於JOIN優化有下面的幾個關鍵點：

接下來看看哪些狀況下，沒法有效使用索引的：

再看看幾個殺手級SQL的案例及其優化建議：

在平時，咱們登入MySQL服務器後，若是以爲有問題，能夠重點關注下面的一些線程狀態：

其餘優化

關於DBA的利器，經常使用percona-toolkit工具簡介：

附：關於MariaDB及Percona分支版本的簡介

Q&A

Q1: 多實例，進程會不會搶佔？每一個事例都是單獨起的。

A：除了OS層面的資源會相互影響外，其餘的不會。好比某個實例消耗特別多cpu資源的話，那麼其餘實例也會跟着受影響，這是必然的，除非用虛擬化等方式作隔離。

Q2: SSD建議單盤仍是Raid？

A：若是不擔憂丟數據，單盤唄。若是怕丟的話，那顯然不能單盤了。隨機io很高的話，Raid5就不合適了。不過除非採用SSD，用Raid5也不怕了。事實上，Raid卡反而會影響（下降）SSD性能的發揮，但爲了數據可靠性，沒辦法，還好影響不算特別大。

Q3: 能介紹一下哪些業務場景適合哪一種RAID嗎？

A：一、高隨機IO，用Raid10；二、須要大容量，用Raid5。基本就這兩種方案，事實上，由於SSD的IOPS性能已經很不錯了，不少企業會選擇直接用3塊盤構建Raid5。毋庸置疑，上了PCIE SSD，能夠避免不少問題，或者DBA能夠少幹不少活，至少能夠緩解。

Q4: nnodb_buffer_pool_instances應該如何設置？

A：ibp的instance通常不超過8爲宜，超過8的話，可能有副作用，不過多個instance的前提是，平均到每一個instance的ibp不能小於2G，不然也沒啥意義。

Q5: No text,or in compressed是指若是使用text的話，建議壓縮嗎？在壓縮數據方面，葉老師有什麼經驗嗎？

A：對的，建議不要在InnoDB中存儲大量文本。須要的話，事先壓縮好再存進去。不須要檢索的文本，能夠通通壓縮後存進去，不是用InnoDB的壓縮格式哦，是事先外部壓縮後存儲，文本內容在存儲進去前先壓縮好，不是用InnoDB的compressed這種row format，那會被坑慘的，性能損失9層，只有一半壓縮比，還不如用TokuDB算了。

Q6: MariaDB和MySQL的優缺點，以及大神怎麼看Maria有否取代MySQL的趨勢？

A：想要取代還早呢，沒那麼容易，並且也不必取代，做爲補充就ok。除非哪天MySQL官方版本閉源了，或者支持不好。

Q7: 新的業務系統，是建議繼續用MySQL5.5或以上，仍是用mariaDB？

A：建議優先Percona 5.6，其次是MySQL 5.6，最末纔是MariaDB。

Q8: 大家的數據庫備份是用Percona的工具進行嗎？每週一全備，天天一增量？用這些工具有份，會不會出現恢復不了的狀況？這個有沒有辦法驗證備份是否「正常」 ？

A：工具則以xtrabackup爲主，mysqldump爲輔，數量不是巨大的話，天天一全備，大多有slave作熱備，因此就沒按期增備了。Mydumper也有些不太爽的，也比較小衆就是，備份文件必定要作恢復性測試，千萬別隻備份不恢復測試，關鍵時刻會死人的。

Q9:恢復性測試怎麼作 有流程方案指導一下嗎？

A：簡單的：數據恢復，簡單查詢驗證數量，關鍵數據什麼的；複雜的：搭測試環境唄。

Q10: 有沒有什麼效率較高的驗證備份有效性的工具或者方法？仍是隻好把庫恢復出來覈對？

A：mysqldump或mydumper備份的文件，能夠用grep簡單快速驗證；xtrabackup的話，只能看文件大小，或者作全量恢復了。