微博MySQL優化之路--dockone微信羣分享

微博MySQL優化之路

數據庫是全部架構中不可缺乏的一環，一旦數據庫出現性能問題，那對整個系統都回來帶災難性的後果。而且數據庫一旦出現問題，因爲數據庫天生有狀態（分主從）帶數據（通常還不小），因此出問題以後的恢復時間通常不太可控，因此，對數據庫的優化是須要咱們花費不少精力去作的。接下來就給你們介紹一下微博數據庫這些年的一點經驗，但願能夠對你們有幫助。

硬件層優化

這一層最簡單，最近幾年相信你們對SSD這個名詞並不陌生，其超高的IOPS在剛出如今你們視野中的時候就讓人驚豔了一把，而隨着最近價格的不斷下調，已經很是具備性價比，目前微博已經把SSD服務器做爲數據庫類服務的標配。

咱們來看下咱們早些年本身對SSD的OLTP的性能測試：



能夠看到OLTP的qps能夠達到2.7w左右，配合1m2s的架構能夠支持5w的qps，在一些簡單場景下，甚至能夠沒必要配置cache層來作緩存。

ps:硬件測試最好本身進行實測，官方數據僅能做爲一個參考值，由於不少時候性能要嚴重依賴於場景，細化到不一樣的SQL會獲得相差很大的結論，故最好自行測試。

微博在12年的時候使用PCIE-FLASH支撐了feed系統在春晚3.5w的qps，在初期很好的支撐了業務的發展，爲架構優化和改造爭取了很是多的時間。

而且你們能夠看到，目前不少的雲廠商的物理機基本全都是SSD設備，AWS更是虛機都提供SSD盤來提供IO性能，能夠預見將來IO將不會在是數據庫遇到的最大瓶頸點。

經驗：若是公司不差錢，最好直接投入SSD or PCIE-FLASH設備，並且投入的時間越早越好。

系統層優化

配合SSD硬件以後，系統層原有的一些設計就出現了問題，好比IO scheduler，系統默認的爲CFQ，主要針對的是機械硬盤進行的優化，因爲機械硬盤須要經過懸臂尋道，因此CFQ是很是適合的。

Complete Fair Queuing
該算法爲每個進程分配一個時間窗口，在該時間窗口內，容許進程發出IO請求。經過時間窗口在不一樣進程間的移動，保證了對於全部進程而言都有公平的發出IO請求的機會。同時CFQ也實現了進程的優先級控制，可保證高優先級進程能夠得到更長的時間窗口。 

可是因爲SSD盤已經沒有了尋道而是基於電子的擦除，因此CFQ算法已經明顯的不合適了，通常狀況下網上都推薦使用NOOP算法，可是我我的更推薦DEADLINE算法。咱們看下這2種算法的特色。

NOOP算法只擁有一個等待隊列，每當來一個新的請求，僅僅是按FIFO的思路將請求插入到等待隊列的尾部，默認認爲 I/O不會存在性能問題，比較節省CPU資源。 DEADLINE調度算法經過下降性能而得到更短的等待時間，它使用輪詢的調度器,簡潔小巧,提供了最小的讀取延遲和尚佳的吞吐量,特別適合於讀取較多的環境。 

從算法的特色看，NOOP確實更適合SSD介質，很是的簡單，可是因爲數據庫型服務有不少複雜查詢，簡單的FIFO可能會形成一些事務很難拿到資源從而一直處於等待狀態，因此我的更推薦使用DEADLINE。ps：更主要的是由於對這2個算法的壓測顯示性能並無太明顯的區別。

如下是咱們本身在線上業務調整以後的效果：



 

除了以上這點以外，還有一些小地方也許要調整，雖然收益不會看上去這麼明顯，可是積少成多，聚沙成塔，仍是很是值得優化的。

• 使用EXT4 or XFS
• 在mount的時候加上 noatime屬性
• raid卡的讀寫策略改成write back
• 使用jemalloc替換現有的Glibc

經驗：重點放在針對IO的優化上，數據庫尤爲是MySQL是IO密集型服務，解決IO的問題會減小沒必要要的問題。

MySQL自身的優化

咱們先說說有那些參數能夠帶來性能的改變

• innodb_max_dirty_pages_pct

爭議比較大，通常來講都是在75-90之間，主要控制BP中的髒數據刷盤的時機，若是過小會頻繁刷盤形成IO上升，若是太大會致使MySQL正常關閉的時候須要很長的時間才能normal shutdown，具體須要看實際場景，我的推薦90

• innodb_io_capacity

磁盤IO吞吐，具體爲緩衝區落地的時候，能夠刷髒頁的數量，默認200，因爲使用了SSD硬盤，因此推薦設置到3000-5000

• innodb_read_io_threads
• innodb_write_io_threads

增長後臺處理線程的數目，默認爲4，推薦改爲8

• sync_binlog
• innodb_flush_log_at_trx_commit 

著名的雙1參數，對性能影響很是的大
sync_binlog控制刷binlog的策略，MySQL在每寫N次 二進制日誌binary log時，會使用fdatasync()函數將它的寫二進制日誌binary log同步到磁盤中去。
innodb_flush_log_at_trx_commit控制log buffer刷log file的策略，設置爲0的時候每秒刷新一次，設置爲1的時候每次commit都會刷新。

從上述描述就能夠看出若是追求數據的安全性，那麼設置雙一是最安全的，若是追求性能最大化，那麼雙0最合適，這中間能夠相差至少2倍的性能。

• innodb_log_file_size

innodb redo log的size大小，5.5最大4G，5.6最大256G，這個越大能夠提高寫的性能，大部分時候不須要等待checkpoint覆蓋就能夠一直write。

• query_cache_type

看上去很美的東西，可是在實際生產環境中，屢次給咱們帶來了故障，因爲每次表的更新都會清空buffer，而且對於sql的匹配是逐個字符效驗實際效果很長，大部分時間並無獲得cache的效果，反而獲得了不少wait for query cache lock。建議關閉。

以上，僅針對MySQL 5.5，目前咱們還在摸索5.6和5.7因爲尚未大規模線上使用，因此還談不上有什麼經驗。

經驗：若是有人力能夠投入，能夠學習BAT針對數據庫進行二次開發，經過path的方式得到更高的性能和穩定性。若是沒有人力，只要深刻了解MySQL自身參數的影響也能夠知足業務的需求，不用一味的追源碼級別的開發改造。

業務優化

所謂的業務優化其實說白了不少時候就是index的優化，咱們DBA常說一條慢SQL就能將上面全部的優化都付之一炬，CPU直接打滿，RT全都都飆升到500ms甚至1s以上。

優化慢查有三寶：

• pt-query-digest
• explain
• show profiling

首先，使用pt-query-digest能夠定位到定位影響最中的慢查是哪條。



而後經過explain具體分析慢查曉的問題所在



重點查看type，rows和extra這三個字段。

其中type的順序以下：

system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL 

最後，若是問題仍是比較嚴重，能夠經過show profiling來定位一下究竟是那個環節出現的問題。



能夠看到sending data最消耗時間，這時候就須要找到底爲何在sending上消耗了這麼多的時間，是結果集太大，仍是io性能不夠了，諸如此類

如下就是一個複雜語句的優化結果，能夠從rows那裏明顯的看出減小了不少查詢的開銷。



經驗：最好創建慢查詢監控系統，天天都花時間在慢查的優化上，避免一條SQL引起的血案之類的事情發生。

架構優化

最後，也就是終極手段了，那就是架構優化，其實不少時候，當咱們將上面幾個方向都作了以後發現尚未很好的效果，那就必須找開發同窗一塊兒聊一下了。ps：固然找PM同窗聊一下人生會更有效果。

記得有一次，咱們找開發聊了一下，最後開發決定將這個功能改掉，這個時候你會忽然發現不管什麼優化手段都比不上「不作」這個優化手段，簡直無敵了。

根據我我的的經驗來講架構層的優化有以下幾個普適原則：

• cache爲王

熱點數據必須使用Redis或者mc之類的cache抗量，讓MySQL抗流量是不明智的。

• 使用隊列消峯

衆所周知MySQL的異步同步機制是單線程的，全部主庫上的併發到從庫上都是經過io-thread來慢慢作的，即便主庫寫入速度再快，從庫延遲了，整個集羣仍是不可用，因此最好採用隊列來進行必定的寫入消峯，使寫入維持在一個較爲均衡的水平。

• 適度的過分設計

不少產品最開始的時候比較小，可是有可能上線以後廣受好評一下用活躍度就上來了，這個時候若是數據庫出現瓶頸須要拆分須要開發、DBA、架構師等等一塊兒配合來作，並且頗有可能沒有時間。因此在產品初期進行必定的過分設計會爲將來這種狀況打好鋪墊。最明顯的就是拆庫拆表，最好在一開始就對業務進行適度的垂直拆分和比較過分的水平拆分，以便應對業務的高速增加。

舉一個栗子：



1. 經過mcq下降對MySQL的寫入性能的要求。
2. 經過mc和Redis來承擔用戶的實際訪問，90%的量依靠cache層承載和屏蔽。
3. MySQL做爲最終的數據落地，存儲全量的數據，可是僅支撐部分業務查詢，小於10%。

經驗：讓合適的軟件作適合的事情，不要光從技術層面思考優化方案，也要從需求方面去分解。

總結中的總結

轉一篇很經典的數據庫優化漏斗法則，不少年前就看到過，如今再看依然以爲適用，你們共勉。



惟一不適用的就是最下的增長資源，SSD真是個好東西，誰用誰知道。