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