解讀MySQL性能調優「金字塔」

時間 2019-11-20

原文原文鏈接

計算機是一種實驗的科學，性能優化是實戰的藝術html

蒸汽機的改進不是一蹴而就的，MySQL性能的改進也是貫穿整個MySQL發展史的。MySQL之父Monty在1981年寫了MySQL的第一行代碼之後，在開源的幫助下MySQL成長爲目前最流行的開源數據庫，一樣其也凝聚了很是多的開發者、DBA、工程師的心血。mysql

本文選自**《千金良方：MySQL性能優化金字塔法則》**一書，將從總體上介紹性能調優的幾個方面，並借用「金字塔」理論依次介紹了硬件和系統調優、MySQL 調優以及架構調優的一些原則和方法。sql

本文介紹的三種調優方法是按照金字塔的調優順序排列的，以下圖所示。通常來講，自底向上調優的效果是成反比的，而越往下層調優效果越好，可是難度也越大。數據庫

按照依賴關係（架構調優要求DBA對MySQL自己有必定的瞭解，MySQL調優依賴於系統和硬件的相關知識）和對專業知識要求的難易程度，咱們按照自上而下的順序（硬件和系統調優、MySQL調優、架構調優）描述案例，而DBA在實際應用過程當中接觸和優化的順序實際上是相反的。在進行優化時，首先須要關注和優化的應該是架構，若是架構不合理，那麼DBA能作的事情實際上是比較有限的。緩存

對於架構調優，在系統設計時首先須要充分考慮業務的實際狀況，是否能夠把不適合數據庫作的事情放到數據倉庫、搜索引擎或者緩存中去作；而後考慮寫的併發量有多大，是否須要採用分佈式；最後考慮讀的壓力是否很大，是否須要讀寫分離。對於核心應用或者金融類的應用，須要額外考慮數據安全因素，數據是否不容許丟失，是否須要採用Galera或者MGR。安全

對於MySQL調優，須要確認業務表結構設計是否合理，SQL語句優化是否足夠，該添加的索引是否都添加了，是否能夠剔除多餘的索引，數據庫的參數優化是否足夠。性能優化

最後肯定系統、硬件有哪些地方須要優化，系統瓶頸在哪裏，哪些系統參數須要調整優化，進程資源限制是否提到足夠高；在硬件方面是否須要更換爲具備更高I/O性能的存儲硬件，是否須要升級內存、CPU、網絡等。若是在設計之初架構就不合理，好比沒有進行讀寫分離，那麼後期的MySQL和硬件、系統優化的成本就會很高，而且還不必定能最終解決問題。若是業務性能的瓶頸是因爲索引等MySQL層的優化不夠致使的，那麼即便配置再高性能的I/O存儲硬件或者CPU也沒法支撐業務的全表掃描。服務器

對於硬件和系統的調優須要在系統上線前，甚至在數據庫選型階段和設計階段就須要考慮起來，若是等驗證測試和上線之後再去考慮提高硬件性能或者調整系統參數，要作的工做就太多了。網絡

▌硬件優化架構

更高頻率的 CPU 能讓複雜的SQL語句在MySQL上運行的速度更快；更大的內存能讓更多的熱點數據緩存在內存中，使得併發效率更高；更快的存儲系統能讓 MySQL 及時存取數據，提高客戶端的響應效率；更高的網絡帶寬和更低的網絡延遲能讓 MySQL 提供更大的吞吐率。硬件優化對數據庫效率的提高很是關鍵。

數據庫之前都運行在小型機上，資源相對較爲充足，以後遷移到 x86 物理機上，大多數時候也能獨佔整個物理機資源，後來因爲互聯網的流行，虛擬化、雲化帶來了很是大的靈活性，可是對於數據庫來講，資源縮減得很是多，而 MySQL 愈來愈「應用化」，一個開發人員或者系統管理員就能夠將其部署起來，壓力不大時使用起來也不會有問題。這樣帶來的問題是，其餘的業務壓力或者I/O壓力可能就讓數據庫變得很緩慢，甚至一條複雜的 SQL語句或者一個SQL語句執行計劃走錯都會讓數據庫響應時間增長几十倍。要達到小型機+存儲的數據庫時代的穩定性和效率，對底層硬件的選型、驗證、資源隔離以及優化就必不可少。CPU、內存、網絡受限於企業環境，可調整和優化的空間比較小，而數據庫最關鍵和最值得關注的就是I/O存儲系統的優化，是選擇普通的機械磁盤仍是Flash介質存儲，RAID怎麼作、怎麼分區，是write back仍是write through，對數據庫的影響很是大。

▌系統優化

因爲硬件資源的限制，也爲了讓系統中運行的各個組件能均衡地使用硬件資源，Linux系統設計和實現了各類資源使用策略。數據庫的操做系統優化從某種程度來講就是理解操做系統的資源使用策略，充分讓數據庫使用更多的硬件資源，發揮硬件性能。例如，爲了不內存空間使用不足而發生崩潰，Linux系統設計了swap（交換區），而且提供了一個swappiness參數，用來設置在什麼狀況下使用swap。當該參數設置爲0時，系統在幾乎沒有內存的狀況下才會使用swap；當其設置爲100時，進程申請的內存很快就會被交換出去，在數據庫場景下，應該將swappiness設置得儘量小，以保證熱點數據儘可能保留在物理內存中。

▌參數調優

參數調優的目的就在於如何適配硬件和系統，在MySQL的服務器層和InnoDB層最大程度地發揮底層的性能，保證業務系統高效。

在Oracle佔據大部分數據庫市場的年代，多個DBA會共同維護一套Oracle數據庫，這套Oracle數據庫承載着多個業務系統，多個Oracle業務系統之間的參數爲了適配業務或者底層硬件，在配置之間不盡相同。在MySQL在互聯網上大放異彩的時代，一個DBA管理着幾套甚至幾十套MySQL數據庫，愈來愈多的MySQL DBA發現，與其爲每一個業務系統進行特殊的參數調優，還不如肯定一個能適配80%業務場景的數據庫版本和數據庫配置模板，而且對應地規範硬件和系統配置，保證多個MySQL系統的標準化和一致性。其實理由很簡單，當規模化之後，必需要進行標準化（好比以前一我的就能夠作一雙皮鞋，爲每一個人定製，價格和成本相對比較高；若是一個工廠天天要作一萬雙皮鞋，就不可能爲每一個人定製了，而必須標準化，經過流水線提高效率），避免排查問題、升級、運維等工做不可控。好比5個不標準的MySQL系統升級到新版本須要準備5套方案，而5個標準的MySQL系統升級到新版本只須要準備1套方案，而且還能夠自動化實現。

固然，並非要非黑即白地去理解這個問題，也不是說MySQL的參數調優就不須要關注了。筆者曾經遇到過一個128GB內存的服務器，因爲MySQL的buffer_pool參數只配置爲128MB致使性能特別差的案例。隨着硬件性能的提高、MySQL數據庫版本的升級、DBA經驗的提高和DBA在實際硬件上的併發測試，你可能會發現有更加適合對應硬件和操做系統的MySQL配置參數值，當驗證經過後，就能夠統一調整升級了。這裏有一個小技巧：將[mysqld]的配置寫在最後。因爲寫在後面的配置會直接覆蓋前面的配置，若是要對MySQL服務器配置進行參數調整，那麼直接在結尾添加參數就能夠了，自動化程序修改起來很是方便，不容易出錯。示例以下：

[client]
port=3306
...

[mysqldump]
default-character-set = utf8
...

[mysql]
no-auto-rehash
...

[mysqld]
default-storage-engine = INNODB
...
# 保證[mysqld]是最後一個MySQL配置組，全部須要調整的參數都添加在此位置後（利用mysqld配置項後面的覆蓋前面的特性）
...
innodb_log_buffer_size = 128M

▌SQL/索引調優

SQL/索引調優要求DBA對業務和數據流很是清楚。在阿里巴巴內部，有三分之二的DBA是業務DBA，從業務需求討論到表結構審覈、SQL語句審覈、上線、索引更新、版本迭代升級，甚至哪些數據應該放到非關係型數據庫中，哪些數據放到數據倉庫、搜索引擎或者緩存中，都須要這些DBA跟蹤和複審。他們甚至能夠稱爲數據架構師（Data Architecher）。開發人員的更替或者業務的迭代致使一些業務邏輯和代碼很難跟蹤，可是不要緊，DBA熟悉每一個表、每一個字段的含義，他們跟蹤業務模塊關係、更新迭代的原因、業務高峯/低谷時哪裏最耗資源、是否還有優化空間等。若是這些數據模型都在的話，就很方便對業務邏輯和代碼診斷和修改了。

如文章開頭的圖所示，金字塔的底部是架構調優，採用更適合業務場景的架構能最大程度地提高系統的擴展性和可用性。在設計中進行垂直拆分能儘可能解耦應用的依賴，對讀壓力比較大的業務進行讀寫分離能保證讀性能線性擴展，而對於讀寫併發壓力比較大的業務在MySQL上也有采用讀寫分離的大量案例。

做爲金字塔的底部，在底層硬件系統、SQL語句和參數都基本定型的狀況下，單個MySQL數據庫能提供的性能、擴展性等就基本定型了。可是經過架構設計和優化，卻能承載幾倍、幾十倍甚至百倍於單個MySQL數據庫能力的業務請求能力。

▌《千金良方：MySQL性能優化金字塔法則》

李春羅小波董紅禹著 MySQL的火熱程度有目共睹，若是須要了解MySQL的安裝、啓動、配置等基礎知識，市面上相關的書籍已經是汗牛充棟。本書則儘可能深刻細緻地介紹MySQL的基本原理，以及性能優化的實際案例。不管你是MySQL初學者，仍是專門從事MySQL工做的開發人員和運維人員，或者是資深的MySQL DBA，都值得一讀！

▶ 關於做者

李春原阿里巴巴MySQL DBA團隊技術Leader，全程參與阿里數據庫架構從Oracle遷移到MySQL的過程，參與分佈式中間件Cobar設計。現爲沃趣科技聯合創始人&首席架構師，負責MySQL、基礎軟件及部分關鍵組件的技術選型、風險評估等。

羅小波沃趣科技高級數據庫工程師，主要負責MySQL產品的數據庫支撐與售後二線支撐。曾參與版本發佈系統、輕量級監控系統、運維管理平臺、數據庫管理平臺的設計與編寫，熟悉MySQL體系結構，Innodb存儲引擎，喜愛專研開源技術，屢次在公開場合作過線下線上數據庫專題分享，發表過多篇與數據庫相關的研究文章。

董紅禹沃趣科技MySQL DBA ，爲過多家大型企業進行過故障解決、架構設計、性能優化，例如中信證券、浙江農信、陝西農信、郵儲銀行等。規劃並實施了浙江農信互聯網核心金融平臺。