技術老鐵們，工作累了，我們就一起來放鬆一下！老張我呢是個金庸迷，在金庸小說中，降龍十八掌無愧巔峰外功，它的威力之大可想而知。而今兒，老張要給大家介紹18招式，來優化我們的 MySQL 資料庫，讓它跑起來更快，更穩定！
之前老有學生問我，張老師該如何優化我們的 MySQL 資料庫呢？這個問題太泛泛了，不是很具體！因為資料庫的優化要從多個角度去考慮，通過不同的維度模型去排查問題。老師整理了下思路，大概可以從18個角度，大致四個方向去給大家一些建議。
第一掌—-亢龍有悔
要想保證資料庫能夠高效，穩定地執行在伺服器上面，我們首先要保證有充足的記憶體，只有記憶體足夠大了，我們才能快取住那些我們經常訪問的熱資料，一些 update 語句的操作當然也可以在記憶體中優先完成。但是我們要考慮記憶體使用黃金分割法則，由於不同業務的存在，對記憶體的需求當然也就不一樣了。
舉個列子來說，使用者經常訪問的熱資料，對於記憶體的分配就要儘可能達到達到資料庫記憶體的 70-80% 左右。眾所周知，我們知道 MySQL 資料庫記憶體主要靠 innodb_buffer_pool，redo log buffer，double write buffer，binlog cache 等組成。如果伺服器上面只跑著 MySQL 一個應用，那大概 innodb_buffer_pool 可以分配到實體記憶體的 50-80% 左右。
TIPS：我們要根據實際實體記憶體的大小，具體是什麼業務型別，去考慮資料庫記憶體的分配。
第二掌—-飛龍在天
要優化 MySQL 資料庫，首先要很瞭解對手，隨著版本的升級，MySQL 用到的 CPU 核數就越多，自從 MySQL 5.6 之後可以使用到 64 個核。MySQL 連線特點的是這樣，每個連線對應一個執行緒，每個 sql/ 查詢只能使用到一個 cpu 核心，所以需要越多的 CPU，並且更快的 CPU。這樣才能有利於提高資料庫效能，提高我們資料庫的併發能力！
TIPS：使用多核 CPU。
第三掌—-見龍在田
眾所周知，IO 對資料庫來說，一直都是瓶頸，並且有可能將來一段時間還會是。所以對儲存介質的要求就非常高，對於 IO 系統比較高的情況下，建議我們要使用更快的儲存裝置 SSD 固態硬碟可提高上百倍的資料讀寫效能或者是 PCIE-SSD 固態硬碟可提高上千倍的資料讀寫能力。像現在的一些電商網站，在搞店慶或者促銷活動的時候，都需要藉助此裝置，來滿足大量使用者的影響請求。
TIPS：建議上高轉速硬體裝置，SSD 或者 PCIE-SSD
第四掌—-鴻漸於陸
自從 web2.0 時代開啟，基本所有的，我們使用的軟體都是基於 linux 平臺自主研發的。我們知道，MySQL 資料庫也是跑在 linux 作業系統上面的。在官方建議估計最推薦的是 Solaris，但從實際生產中的角度來看 CentOS 和 REHL 都是不錯的選擇，個人建議推薦使用 CentOS, 如果非要使用 REHL，建議 版本為6以後的，這裡就不推薦使用在 windows 下跑 MySQL 資料庫了，雖然隨著 MySQL 版本提升，對 windows 有了相關的優化，但是對於高併發，高負載的環境來說，依舊不建議使用。
TIPS：推薦使用 CentOS，或者 REHL 作業系統型別
第五掌—-潛龍勿用
作業系統層面的優化，我們要考慮個可能大家會比較忽略的問題，首先就是 swappiness 的問題。swappiness 的值大小對如何使用 swap 分割槽有著密切的聯絡。有兩個極限值，一個為 0，另一個為 100，檢視可執行 cat /proc/sys/vm/swappiness。
0 代表：最大限度地使用實體記憶體，然後才是 swap 分割槽，這種行為有可能導致系統記憶體溢位，從而導致mysql被意外kill掉。不建議這樣去設定。
100則為：積極地使用使用 swap 分割槽，並且把記憶體上面的資料及時搬到 swap 分割槽裡。
TIPS：這裡比較建議使用預設 60 就可以。
第六掌—-利涉大川
與 swappiness 對應的，另一個作業系統層面的優化，還有一個小細節點就是 IO 排程。這裡有 cfq，noop 和 deadline，系統預設使用 cfq，這裡老師建議使用 deadline。檢視方法：
cat /sys/block/sda/queue/scheduler/
TIPS：deadline 可以調整讀寫時間，避免寫完沒有被讀取的餓死場景。
第七掌—-突如其來
Oracle 11g 之後多了一個 result_cache，來快取資料結果集。MySQL 裡面通過 innodb_buffer_pool 裡面有個 query cache 來快取靜態結果集。我們都希望熱資料都儲存在記憶體裡面，我們讀取資料快速便捷，資料庫的快取率也很高！但資料庫中的 query cache 裡面的資料一但發生更改，此快取區毫無意義，就會變成雞肋。而且如果開啟 Query Cache，更新與寫入都要去檢查 query cache 反而增加了寫入的開銷。
TIPS：建議關閉 query cache
第八掌—-震驚百里
對於磁碟陣列，我們再熟悉不過了，但是對於陣列卡的 cache 策略，我們又該如何選擇呢。首先對於qps，tps，業務高的系統，一定要配置陣列卡，配 cache 模組，和 BBU 模組（用於提供後備電量）。
cache 策略有兩種，一種為：write through（WT）；另一種為：write back；
個人強烈建議使用 write back（WB）。WT含義，資料直接寫入磁碟，WB含義：資料先寫陣列卡的cache，再由cache寫入磁碟，這樣對於寫入的效能有所提高。並且對於加速redo log ,binlog, data file都有好處。
TIPS：強烈建議陣列卡的 cache 策略使用 write back。
第九掌—-或躍在淵
前面也涉及到了，儘可能大的給 innodb_buffer_pool 分配空間，在伺服器只跑資料庫一個應用前提下大概為實體記憶體 50-80%。
TIPS：建議應用與資料庫分開部署在伺服器上面，後期好排查問題。
第十掌—-雙龍取水
MySQL 資料庫的一些核心引數，我們要在心裡銘記。比如雙一的含義，直接影響日誌的重新整理機制。影響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 中的資料強制寫入磁碟。為了確保安全性，我們可以將sync_binlog=1。為了獲得最佳效能我們可以將sync_binlog=0。
TIPS：對於不同業務的公司，保障的點不一樣，所有我們要考慮好，是業務最重要，還是資料最重要！然後分別去設定不同的引數value
第十一掌—-魚躍於淵
MySQL 資料庫區別於其他資料庫最主要就是外掛式儲存引擎，最為著名就是 myisam 還有 innodb。它們都有各自的特點，這裡強烈建議使用 innodb 儲存引擎表，無論是對於事務的支援，還是線上 DDL 語句快速操作，它都是目前最優秀的儲存引擎！MySQL 5.5 之後預設使用的儲存引擎都是 innodb
TIPS：生產環境中，如果還有 myisam 這種儲存引擎的表，建議全部做 myisam–>innodb 儲存引擎的轉換！不過 MySQL 5.7之後，系統表也都是 innodb 了！
第十二掌—-時乘六龍
檔案系統強烈推薦使用 xfs，不要再使用 ext3,ext4 之類的，因為 xfs 這種檔案系統也是 B-tree 結構最接近於資料庫的樹狀結構。
第十三掌—-密雲不雨
生產環境中，經常會出現對大表進行 delete，或者 update 這類的操作。資料碎片隨之產生，我們要經常去整理主要業務表的碎片，讓查詢檢索更快。可以通過 pt-ioprofile 監控與磁碟互動最為緊密的表，然後通過 alter table 或者匯入匯出資料的方法對錶進行碎片整理。儘可能回收表空間
第十四掌—-損則有孚
利用天兔（lepus）或者 zabbix 做好對資料庫的監控。監控事項可以從伺服器的狀態，記憶體的使用情況，cpu的負載。資料庫中每秒的增刪改查資訊，架構中的延遲和複製狀態資訊去作為監控的核心點。
第十五掌—-龍戰於野
配合開發人員合理地設計表結構，秉著越簡單越好的原則，去選擇合適欄位的資料型別。對於ipv4，時間型別的欄位，我們完全可以通過整型int來存取！通過函式轉換就可以了！
ip涉及到兩個函式：inet_aton和inet_ntoa
時間型別的兩個函式：from_unixtime和unix_timestamp
第十六掌—-事務隔離級別的選擇
mysql資料庫中，有四種事務隔離級別。它們分別是Read Uncommitted（RU），Read Committed（RC），Repeatable Read（RR），Serializable（SR）。對於交易型別系統的網站，對於事務要求比較高，我們建議使用RR這種隔離級別。
第十七掌—-羝羊觸藩
更改檔案控制程式碼 ulimit –n 預設1024 太小
程式數限制 ulimit –u 根據不同版本來決定
禁掉NUMA numctl –interleave=all
第十八掌—-神龍擺尾
做過資料庫的同學們，可以經常會遇到too many connections這樣的問題，對於這樣的問題，我們一定要做好配置資料庫內部併發的情況。innodb_thread_concurrency 這個引數來決定innodb的併發情況。預設的大小是0。在mysql5.7版本中，增加了thread pool，連線複用的存在，可以取預設值就ok。但是5.7之前的版本，就需要考量一下取值了，個人建議mysql5.6版本中設定為36。mysql5.6之前可以8-32。
降龍十八掌已經打完，希望對於資料庫愛好者，從事資料庫工作中的同學來說有幫助。讓我們每天學習一點點，把自己的內功練得越來越深厚，打出屬於自己的武功。讓我們的資料庫飛起來！