數(shù)據(jù)庫優(yōu)化之降龍十八掌

技術老鐵們，工作累了，我們就一起來放松一下！老張我呢是個金庸迷，在金庸小說中，降龍十八掌無愧巔峰外功，它的威力之大可想而知。而今兒，老張要給大家介紹18招式，來優(yōu)化我們的 MySQL 數(shù)據(jù)庫，讓它跑起來更快，更穩(wěn)定！

之前老有學生問我，張老師該如何優(yōu)化我們的 MySQL 數(shù)據(jù)庫呢？這個問題太泛泛了，不是很具體！因為數(shù)據(jù)庫的優(yōu)化要從多個角度去考慮，通過不同的維度模型去排查問題。老師整理了下思路，大概可以從18個角度，大致四個方向去給大家一些建議。

第一掌----亢龍有悔

要想保證數(shù)據(jù)庫能夠高效，穩(wěn)定地運行在服務器上面，我們首先要保證有充足的內(nèi)存，只有內(nèi)存足夠大了，我們才能緩存住那些我們經(jīng)常訪問的熱數(shù)據(jù)，一些 update 語句的操作當然也可以在內(nèi)存中優(yōu)先完成。但是我們要考慮內(nèi)存使用黃金分割法則，由于不同業(yè)務的存在，對內(nèi)存的需求當然也就不一樣了。

舉個列子來說，用戶經(jīng)常訪問的熱數(shù)據(jù)，對于內(nèi)存的分配就要盡可能達到達到數(shù)據(jù)庫內(nèi)存的 70-80% 左右。眾所周知，我們知道 MySQL 數(shù)據(jù)庫內(nèi)存主要靠 innodb_buffer_pool，redo log buffer，double write buffer，binlog cache 等組成。如果服務器上面只跑著 MySQL 一個應用，那大概 innodb_buffer_pool 可以分配到物理內(nèi)存的 50-80% 左右。

TIPS：我們要根據(jù)實際物理內(nèi)存的大小，具體是什么業(yè)務類型，去考慮數(shù)據(jù)庫內(nèi)存的分配。

第二掌----飛龍在天

要優(yōu)化 MySQL 數(shù)據(jù)庫，首先要很了解對手，隨著版本的升級，MySQL 用到的 CPU 核數(shù)就越多，自從 MySQL 5.6 之后可以使用到 64 個核。MySQL 連接特點的是這樣，每個連接對應一個線程，每個 sql/ 查詢只能使用到一個 cpu 核心，所以需要越多的 CPU，并且更快的 CPU。這樣才能有利于提高數(shù)據(jù)庫性能，提高我們數(shù)據(jù)庫的并發(fā)能力！

TIPS：使用多核 CPU。

第三掌----見龍在田

眾所周知，IO 對數(shù)據(jù)庫來說，一直都是瓶頸，并且有可能將來一段時間還會是。所以對存儲介質(zhì)的要求就非常高，對于 IO 系統(tǒng)比較高的情況下，建議我們要使用更快的存儲設備 SSD 固態(tài)硬盤可提高上百倍的數(shù)據(jù)讀寫性能或者是 PCIE-SSD 固態(tài)硬盤可提高上千倍的數(shù)據(jù)讀寫能力。像現(xiàn)在的一些電商網(wǎng)站，在搞店慶或者促銷活動的時候，都需要借助此設備，來滿足大量用戶的影響請求。

TIPS：建議上高轉(zhuǎn)速硬件設備，SSD 或者 PCIE-SSD

第四掌----鴻漸于陸

自從 web2.0 時×××啟，基本所有的，我們使用的軟件都是基于 linux 平臺自主研發(fā)的。我們知道，MySQL 數(shù)據(jù)庫也是跑在 linux 操作系統(tǒng)上面的。在官方建議估計最推薦的是 Solaris，但從實際生產(chǎn)中的角度來看 CentOS 和 REHL 都是不錯的選擇，個人建議推薦使用 CentOS, 如果非要使用 REHL，建議 版本為6以后的，這里就不推薦使用在 windows 下跑 MySQL 數(shù)據(jù)庫了，雖然隨著 MySQL 版本提升，對 windows 有了相關的優(yōu)化，但是對于高并發(fā)，高負載的環(huán)境來說，依舊不建議使用。

TIPS：推薦使用 CentOS，或者 REHL 操作系統(tǒng)類型

第五掌----潛龍勿用

操作系統(tǒng)層面的優(yōu)化，我們要考慮個可能大家會比較忽略的問題，首先就是 swappiness 的問題。swappiness 的值大小對如何使用 swap 分區(qū)有著密切的聯(lián)系。有兩個極限值，一個為 0，另一個為 100，查看可執(zhí)行 cat /proc/sys/vm/swappiness。

0 代表：最大限度地使用物理內(nèi)存，然后才是 swap 分區(qū)，這種行為有可能導致系統(tǒng)內(nèi)存溢出，從而導致mysql被意外kill掉。不建議這樣去設置。

100則為：積極地使用使用 swap 分區(qū)，并且把內(nèi)存上面的數(shù)據(jù)及時搬到 swap 分區(qū)里。

TIPS：這里比較建議使用默認 60 就可以。

第六掌----利涉大川

與 swappiness 對應的，另一個操作系統(tǒng)層面的優(yōu)化，還有一個小細節(jié)點就是 IO 調(diào)度。這里有 cfq，noop 和 deadline，系統(tǒng)默認使用 cfq，這里老師建議使用 deadline。查看方法：

cat /sys/block/sda/queue/scheduler/ 

TIPS：deadline 可以調(diào)整讀寫時間，避免寫完沒有被讀取的餓死場景。

第七掌----突如其來

Oracle 11g 之后多了一個 result_cache，來緩存數(shù)據(jù)結果集。MySQL 里面通過 innodb_buffer_pool 里面有個 query cache 來緩存靜態(tài)結果集。我們都希望熱數(shù)據(jù)都保存在內(nèi)存里面，我們讀取數(shù)據(jù)快速便捷，數(shù)據(jù)庫的緩存率也很高！但數(shù)據(jù)庫中的 query cache 里面的數(shù)據(jù)一但發(fā)生更改，此緩存區(qū)毫無意義，就會變成雞肋。而且如果開啟 Query Cache，更新與寫入都要去檢查 query cache 反而增加了寫入的開銷。

TIPS：建議關閉 query cache

第八掌----震驚百里

對于磁盤陣列，我們再熟悉不過了，但是對于陣列卡的 cache 策略，我們又該如何選擇呢。首先對于qps，tps，業(yè)務高的系統(tǒng)，一定要配置陣列卡，配 cache 模塊，和 BBU 模塊（用于提供后備電量）。

cache 策略有兩種，一種為：write through（WT）；另一種為：write back；

個人強烈建議使用 write back（WB）。WT含義，數(shù)據(jù)直接寫入磁盤，WB含義：數(shù)據(jù)先寫陣列卡的cache，再由cache寫入磁盤，這樣對于寫入的性能有所提高。并且對于加速redo log ,binlog, data file都有好處。

TIPS：強烈建議陣列卡的 cache 策略使用 write back。

第九掌----或躍在淵

前面也涉及到了，盡可能大的給 innodb_buffer_pool 分配空間，在服務器只跑數(shù)據(jù)庫一個應用前提下大概為物理內(nèi)存 50-80%。

TIPS：建議應用與數(shù)據(jù)庫分開部署在服務器上面，后期好排查問題。

第十掌----雙龍取水

MySQL 數(shù)據(jù)庫的一些核心參數(shù)，我們要在心里銘記。比如雙一的含義，直接影響日志的刷新機制。影響redo log buffer 的刷新機制

innodb_flush_log_at_trx_commit  = 1（最安全）

innodb_flush_log_at_trx_commit  = 2 （性能一般）

innodb_flush_log_at_trx_commit  = 0 （性能最好）。

影響binlog cache的刷新機制~sync_binlog=0，當事務提交之后，MySQL 不做 fsync 之類的磁盤同步指令刷新 binlog_cache 中的信息到磁盤，而讓 Filesystem 自行決定什么時候來做同步，或者 cache滿了之后才同步到磁盤。sync_binlog=n，當每進行 n 次事務提交之后，MySQL 將進行一次 fsync 之類的磁盤同步指令來將 binlog_cache 中的數(shù)據(jù)強制寫入磁盤。為了確保安全性，我們可以將sync_binlog=1。為了獲得最佳性能我們可以將sync_binlog=0。

TIPS：對于不同業(yè)務的公司，保障的點不一樣，所有我們要考慮好，是業(yè)務最重要，還是數(shù)據(jù)最重要！然后分別去設置不同的參數(shù)value

第十一掌----魚躍于淵

MySQL 數(shù)據(jù)庫區(qū)別于其他數(shù)據(jù)庫最主要就是插件式存儲引擎，最為著名就是 myisam 還有 innodb。它們都有各自的特點，這里強烈建議使用 innodb 存儲引擎表，無論是對于事務的支持，還是在線 DDL 語句快速操作，它都是目前最優(yōu)秀的存儲引擎！MySQL 5.5 之后默認使用的存儲引擎都是 innodb

TIPS：生產(chǎn)環(huán)境中，如果還有 myisam 這種存儲引擎的表，建議全部做 myisam-->innodb 存儲引擎的轉(zhuǎn)換！不過 MySQL 5.7之后，系統(tǒng)表也都是 innodb 了！

第十二掌----時乘六龍

文件系統(tǒng)強烈推薦使用 xfs，不要再使用 ext3,ext4 之類的，因為 xfs 這種文件系統(tǒng)也是 B-tree 結構最接近于數(shù)據(jù)庫的樹狀結構。

第十三掌----密云不雨

生產(chǎn)環(huán)境中，經(jīng)常會出現(xiàn)對大表進行 delete，或者 update 這類的操作。數(shù)據(jù)碎片隨之產(chǎn)生，我們要經(jīng)常去整理主要業(yè)務表的碎片，讓查詢檢索更快?？梢酝ㄟ^ pt-ioprofile 監(jiān)控與磁盤交互最為緊密的表，然后通過 alter table 或者導入導出數(shù)據(jù)的方法對表進行碎片整理。盡可能回收表空間

第十四掌----損則有孚

利用天兔（lepus）或者 zabbix 做好對數(shù)據(jù)庫的監(jiān)控。監(jiān)控事項可以從服務器的狀態(tài)，內(nèi)存的使用情況，cpu的負載。數(shù)據(jù)庫中每秒的增刪改查信息，架構中的延遲和復制狀態(tài)信息去作為監(jiān)控的核心點。

第十五掌----龍戰(zhàn)于野

配合開發(fā)人員合理地設計表結構，秉著越簡單越好的原則，去選擇合適字段的數(shù)據(jù)類型。對于ipv4，時間類型的字段，我們完全可以通過整型int來存取！通過函數(shù)轉(zhuǎn)換就可以了！

ip涉及到兩個函數(shù)：inet_aton和inet_ntoa

時間類型的兩個函數(shù)：from_unixtime和unix_timestamp

第十六掌----事務隔離級別的選擇

mysql數(shù)據(jù)庫中，有四種事務隔離級別。它們分別是Read Uncommitted（RU），Read Committed（RC），Repeatable Read（RR），Serializable（SR）。對于交易類型系統(tǒng)的網(wǎng)站，對于事務要求比較高，我們建議使用RR這種隔離級別。

第十七掌----羝羊觸藩

更改文件句柄  ulimit –n 默認1024 太小

進程數(shù)限制  ulimit –u   根據(jù)不同版本來決定

禁掉NUMA  numctl –interleave=all

第十八掌----神龍擺尾

做過數(shù)據(jù)庫的同學們，可以經(jīng)常會遇到too many connections這樣的問題，對于這樣的問題，我們一定要做好配置數(shù)據(jù)庫內(nèi)部并發(fā)的情況。innodb_thread_concurrency 這個參數(shù)來決定innodb的并發(fā)情況。默認的大小是0。在mysql5.7版本中，增加了thread pool，連接復用的存在，可以取默認值就ok。但是5.7之前的版本，就需要考量一下取值了，個人建議mysql5.6版本中設置為36。mysql5.6之前可以8-32。

降龍十八掌已經(jīng)打完，希望對于數(shù)據(jù)庫愛好者，從事數(shù)據(jù)庫工作中的同學來說有幫助。讓我們每天學習一點點，把自己的內(nèi)功練得越來越深厚，打出屬于自己的武功。讓我們的數(shù)據(jù)庫飛起來！