學習編程技術，關注這個公衆號足夠了html
本文轉載java知音
java
與全部的關係型數據庫同樣，Mysql彷彿是一頭讓人難以琢磨的怪獸。它會隨時停擺，讓應用限於停滯，或者讓你的業務處於危險之中。程序員
事實上，許多最多見的錯誤都隱藏在MySQL性能問題的背後。爲了確保你的MySQL服務器可以一直處於全速運行的狀態，提供持續穩定的性能，杜絕這些錯誤是很是重要的。然而，這些錯誤又每每隱藏在工做負載和配置問題之中。web
幸運的是，許多MySQL性能問題都有着類似的解決方案，這使得排除故障與調整MySQL成爲了一項易於管理的任務。如下就是10個讓MySQL發揮最佳性能的技巧。sql
一、分析工做負載數據庫
經過分析工做負載，你可以發現進一步調整中最昂貴的查詢。在這種狀況下，時間是最重要的東西。由於當你向服務器發出查詢指令時，除了如何快速完成查詢外，你不多關注其餘的東西。分析工做負載的最佳方式是，使用諸如MySQL Enterprise Monitor的查詢分析器，或者Percona Toolkit的pt-query-digest等工具。編程
這些工具可以捕捉服務器所執行的查詢，以降序的方式根據響應時間列出任務列表。它們會將最昂貴的和最耗時的任務置頂，這樣你就能知道本身須要重點關注哪些地方。工做負載分析工具將類似的查詢匯聚在一行中，容許管理者查看速度慢的查詢，以及查看速度快但已屢次執行的查詢。小程序
二、理解四個基本資源服務器
功能性方面，一個數據庫服務器須要四個基本資源：CPU、內存、硬盤和網絡。若是這四個資源中任何一個性能弱、不穩定或超負載工做，那麼就可能致使整個數據庫服務器的性能低下。理解基本資源在兩個特定的領域中相當重要：選擇硬件和排除故障。微信
在爲MySQL選擇硬件時，應該確保所有選用性能優異的組件。這些組件相互匹配，彼此間可以實現合理平衡也很重要。一般狀況下，企業會爲服務器選擇速度快的CPU和硬盤，可是內存卻嚴重不足。在一些案例中，大幅提高性能的最廉價方式是增長內存，尤爲是對於那些受制於磁盤讀取速度的工做負載。這彷佛看起來有點違背常理，可是在許多案例中，因爲沒有充足的內存以保存服務器正在使用的數據，所以致使了硬盤被過分使用。
關於獲取這種平衡的另外一個例子是CPU。在許多案例中，若是CPU速度快，那麼MySQL的性能就很是出色，由於每個查詢都是單線程運行，而沒法在CPU間並行運行。在進行故障排除時，應該檢查這四個資源的性能和使用狀況，關注它們是否性能低下或是超負荷工做。這方面的知識可以幫助你快速地解決問題。
三、不要將MySQL做爲隊列使用
隊列以及與隊列類似的訪問方案會在你不知情的狀況下悄悄地進入應用之中。例如，你設置了一個項目狀態，以便在執行前，特定的Worker Process（工做進程）可以對其進行標記，那麼你就等於在無心間建立了一個隊列。例如，將電子郵件標記爲未發送，而後發送它們，最後再將它們標記爲已發送。
隊列會致使出現一些問題，這裏面有兩大主要緣由：它們對工做負載進行了序列化，阻礙任務被並行處理。這致使正在處理中的任務和之前在工做中處理過的歷史數據會被根據序列排列在一個表單中。這樣一來既增長了應用的延時，也增長了MySQL的負載。
四、以最廉價的方式過濾結果
優化MySQL的最佳方式是首先要作廉價和不精確的工做，而後再小規模地作困難的精確工做，最後再生成數據集。
例如，假設你計算某一個地理座標點給定半徑內的面積。在許多程序員的工具箱裏第一個工具就是球面半正矢公式，以計算出球面的長度。這一方法的問題是，該方程式須要許多三角函數運算，須要擁有很強運算能力的CPU。球面半正矢計算不只運行速度慢，並且會致使機器CPU的使用率飆升。在使用球面半正矢公式前，你能夠先分解計算。有些分解計算並不須要使用三角函數。
五、弄清兩個擴展性死亡陷阱
擴展性可能並不像你認爲的那樣模糊。實際上，擴展性有着精確的數學定義，它們以方程式的形式被表示出來。這些方程式既指出了系統沒法擴展的緣由，同時也指出了它們應該進行擴展的緣由。通用擴展定律（Universal Scalability Law）揭示和量化了系統的擴展性特徵。其經過兩個基礎性成本解釋了擴展問題：即序列化與串擾（Crosstalk）。
並行處理要求必須停止序列化，這就限制了它們的擴展性。一樣的，若是並行處理須要始終進行彼此對話以協調工做，那麼它就相互進行了限制。爲了不序列化與串擾，應用進行了更好的擴展。這些在MySQL內部被翻譯成了什麼？結果不盡相同。不過，一些案例應該避免鎖定在特定的行之中。就像第3個技巧中所提到的，隊列擴展性差的緣由就是如此。
六、不要過度關注配置
數據庫管理員會花費許多時間調整配置。調整的結果一般不會有很大的改善，相反有時候會帶來損害。我發現許多通過「優化的」服務器，在進行強度稍微高一點的運算時經常出現崩潰、內存不足和性能低下等問題。
雖然MySQL在交付時的默認設置嚴重過期，可是你並不須要對每一項都進行配置。最好是根據須要，進行基本糾正與設置調整。有10個選項調整正確，便可讓服務器發揮95%的最大性能。在許多案例中，咱們並不推薦所謂的調整工具，由於它們只是提供一個大概設置，對特定案例沒有任何意義。有些工具甚至包含有危險的和錯誤的設備代碼。
七、注意分頁查詢
分頁查詢應用會使服務器性能大降。這些應用會在網頁上顯示搜索結果，而後經過連接跳轉至相應網頁上。一般這些應用沒法使用索引進行聚合與分類，而是使用LIMIT和OFFSET語句，這致使服務器工做負載大幅增長，並放棄行。 在用戶界面上經常會發現優化選項。替代在結果中顯示網頁數量，以及分別與每一個網頁相連的連接。這樣即可以僅顯示至下一頁的連接。你還能夠阻止查詢者瀏覽與首頁過遠的網頁。
八、保存統計數據，提升報警閥值
監控與報警必不可少，可是監控系統被怎麼處理了呢？當它們發佈假的報警信息時，系統管理員會設置電子郵件過濾規則，以中止這些噪音。很快你的監控系統就完全沒用了。我的認爲，應該如下面的兩種方式進行監控：捕捉指標與報警。儘量地捕捉與保存指標很是重要，由於在你試圖搞明白系統中須要作哪些調整時，你會慶幸以前保存了它們。若是某一天出現奇怪問題時，你會很高興本身有能力繪製出服務器工做負載變化的圖形。
九、瞭解索引的三大規則
索引多是數據庫中被誤解最多的一項。由於它們的工做方式有許多種，這致使人們經常對索引如何工做，以及服務器如何使用它們感到困惑。要想完全搞清楚它們須要花上很大一番功夫。在被正確設計時，索引在數據庫中主要用於實現如下三個重要目的：
1）它們讓服務器尋找相鄰行羣組，而不是單個行。許多人認爲，索引的目的是尋找單個行，可是尋找單個行會致使隨時磁盤操做，速度很慢。尋找行羣組就要好許多，與一次尋找一個行相比，這更具吸引力。
2）它們讓服務器避免以指望的讀行順序對檢索結果排序，排序成本十分高昂。以指望的順序讀行速度將更快。
3）它們可以知足來自一個索引的全部查詢，從根本上避免了訪問表單的需求。這被稱爲覆蓋索引或索引查詢。
若是你能設計出符合這三個規則的索引與查詢，那麼你的查詢速度將大幅提高。
十、利用同行的專業知識
不要孤軍奮戰。若是你在苦苦思考某個問題，並着手製訂明智的解決方案，那麼這很是不錯。在20次中，有19次問題會被順利解決。可是其中會有一次讓你不知所措，致使耗費大量的資金和時間，準確地說，是由於你正在嘗試的解決方案只是貌似合理。
建立一個MySQL相關資源網的意義遠遠大於工具集與故障排除指南。許多經驗豐富的專業人員就隱藏在論壇、問答網站之中。會議、展覽以及本地用戶集體活動，都會爲咱們提供得到新看法的機會和與同行創建聯繫的機會，關鍵時刻這將對你頗有幫助。
來源：軟件測試網
連接：http://www.51testing.com/html/26/n-815126.html
喜歡本文的朋友們，歡迎長按下圖關注訂閱號成猿之路，收看更多精彩內容！
推薦閱讀：
本文分享自微信公衆號 - 成猿之路（softwareload）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。