MySQL的10個基本效能技巧

與所有的關係資料庫一樣，MySQL正如一頭怪獸一般，
它可能會在接到通知的一瞬間陷入停頓，讓你的應用程式陷入困境，讓你的業務處於危險之中。真是的情況是，常見的錯誤是導致MySQL效能問題的根源。
工作負載或配置陷阱中的一些微妙之處常常會掩蓋這些資訊，為了確保MySQL伺服器以最快的速度執行，提供穩定一致的效能，消除這些錯誤是很重要的。
幸運的是，很多MySQL的效能問題都有相似的解決方案，使的故障排除和調優MySQL成為一項易於管理的任務。

MySQL效能提示1:配置您的工作負載

瞭解伺服器究竟把時間花在哪些地方的最佳方法是分析伺服器的工作負載,
通過分析工作負載，您可以匯出最大代價的查詢以進行進一步調優，當向伺服器發出請求的時候，時間就是最重要的指標，
你幾乎不關心任何事情，只關心它完成得有多快。配置工作負載的最佳方法是使用MySQL Enterprise Monitor的查詢分析器或Percona工具包中的pt-query-digest之類的工具。

這些工具捕獲伺服器執行的查詢，並返回一個任務表，按照響應時間的順序進行排序，立即將代價最大和最耗時的任務排在最前面，這樣您就可以看到您的工作重點在哪裡。
工作負載分析工具將類似的查詢組合在一起，允許您檢視緩慢的查詢，以及快速但多次執行的查詢。

譯者注:找到一些top的sql或者說是執行頻率高的sql,這部分是關注的重點

MySQL效能提示2:瞭解四種基本資源

為了完成資料庫服務的功能，資料庫伺服器需要四種基本的資源：CPU，記憶體，磁碟以及網路，
如果其中任意一項是弱項（瓶頸），不穩定或者超負荷，那麼，資料庫伺服器的效能很可能很差。
瞭解基本資源在兩個特定領域非常重要:選擇硬體和故障排除問題。
在為MySQL選擇硬體時，確保所有元件都具有良好的效能。同樣重要的是，要很好地平衡它們。
通常，購買組織會選擇具有快速cpu和磁碟的伺服器，但這些伺服器記憶體不足。在某些情況下，增加記憶體是提高效能的一種廉價方法，尤其是在磁碟繫結的工作負載上。
這看起來似乎違反直覺，但在許多情況下，磁碟被過度使用，因為沒有足夠的記憶體來容納伺服器的工作資料集。

這種平衡的另一個很好的與cpu有關的例子。
在大多數情況下，MySQL在使用快速cpu時表現良好，因為每個查詢在單個執行緒中執行，不能在cpu之間並行化。
在進行故障排除時，請檢查所有4種資源的效能和利用率，並仔細檢查它們的效能是否很差，或者是否出現某些硬體超負載執行。這些知識可以幫助快速解決問題。

譯者注:CPU，記憶體，磁碟以及網路需要匹配,任何一個短板,都可能造成效能上的問題

MySQL效能提示3:不要把MySQL當做佇列使用

佇列和類似佇列的訪問模式可以在您不知情的情況下潛入應用程式。
例如，如果您設定了一個專案的狀態，以便某個特定的工作程序可以在對其進行操作之前宣告它，那麼您無意中建立了一個佇列。
將電子郵件標記為未傳送，傳送，然後標記為傳送是一個常見的例子。
佇列導致問題的主要原因有兩個:它們序列化您的工作負載，防止任務被並行執行，並且它們常常導致一個表，其中包含正在處理的工作以及來自很久以前處理的任務的歷史資料。
既增加了應用程式的延遲，又將其載入到MySQL。

譯者注:MySQL不是做佇列使用的,不要使用高頻率的定時任務像用佇列一樣去刷資料庫。

MySQL效能提示4:先過濾最代價最小的結果
優化MySQL的一個好方法是先做一些廉價的、不精確的工作，然後再對較小的資料集進行艱苦的、精確的工作。
例如，假設您在一個給定的地理點半徑範圍內尋找某物。
許多程式設計師工具箱中的第一個工具是計算球體表面距離的大圓公式。
這種技術的問題是，這個公式需要大量的三角運算，這是非常cpu密集型的運算。大圓計算往往執行緩慢，使計算機的CPU利用率飆升。
在應用大圓公式之前，將您的記錄減少到總數的一小部分，並將結果集修剪到一個精確的圓。
一個包含圓(精確或不精確)的正方形是一個簡單的方法。這樣一來，方塊外的世界就不會受到那些昂貴三角函式的衝擊。

譯者注:沒看懂

MySQL效能提示5:瞭解兩個可伸縮性死亡陷阱

可伸縮性並不像您所認為的那樣模糊。事實上，對於可伸縮性有精確的數學定義，可以用方程表示。這些方程強調了為什麼系統不能像應有的那樣伸縮。
以通用可伸縮性定律為例，該定義在表示和量化系統的可伸縮性特徵方面非常方便。它從兩個基本成本的角度解釋了擴充套件問題:序列化和串擾。
為了實現序列化而必須停止的並行程序在可伸縮性方面天生有限。同樣地，如果並行程序需要一直彼此聊天來協調它們的工作，那麼它們就限制了彼此。
避免序列化和串擾，您的應用程式將更好地擴充套件。這在MySQL中意味著什麼?
它會有所不同，但是有些例子會避免排它鎖。由於這個原因，上面第三點的佇列往往難以擴充套件。

譯者注:沒看懂

MySQL效能提示6:不要過渡關注配置

dba傾向於花費大量時間來調整配置。結果通常不是很大的改善，有時甚至是適得其反的。
我看到過很多“優化”過（調整過某些配置引數）的伺服器，在負載較重的時候，經常崩潰宕機、記憶體不足、效能表現的很差。
MySQL自帶的預設設定是一刀切的，而且已經過時了，但是您不需要配置所有內容，並不意味著任何配置選項都要人為修改。
只有在需要的時候，最好是在瞭解其背景的情況下再去更改配置項。
在大多數情況下，通過正確設定10個（左右，常用）選項，您可以獲得95%的伺服器峰值效能。只有極少數情況下需要修改一些特殊的配置項。

在大多數情況下，不建議使用伺服器“調優”工具，因為它們往往提供的指導方針對特定情況沒有意義。
有些甚至有危險的、不準確的建議，比如快取命中率和記憶體消耗公式。這些永遠都不對，而且隨著時間的流逝，它們變得越來越不正確。

譯者注:大多數情況下主需要關注幾個基本配置就可以了，不需要關注所有的配置資訊，隨意修改配置，有可能會導致適得其反，
有人會說修改bufferpool配置之後效能怎麼怎麼樣，因為由一些本來就很low的錯誤引起的問題，並不是需要過渡關注配置的理由。

MySQL效能提示7:注意分頁查詢

涉及分頁的應用程式往往會使伺服器陷入癱瘓。
應用程式中在向您顯示一個結果頁面時，有一個連結指向下一個頁面，
這些應用程式通常以無法使用索引的方式進行分組和排序，導致伺服器消耗大量的資源，然後根據頁面和顯示行數的要求，然後顯示這其中一部分資料。

優化常常可以在使用者介面中找到。您可以只顯示到下一個頁面的連結，而不是顯示結果和每個頁面的連結的確切數目。
您還可以防止人們轉到離首頁太遠的頁面。

在查詢端，您可以選擇比需要的多一行，而不是使用LIMIT和offset（進行精確地顯示具體的行），
當用戶單擊“下一頁”連結時，您可以指定最後一行作為下一組結果的起點。
例如，如果使用者查看了第101行到第120行的頁面，那麼還可以選擇第121行;
要呈現下一頁，您需要查詢伺服器上大於或等於121的行，限制21。

譯者注:這裡作者應該是想表達，分頁的時候，如果沒有合適的索引，每一次翻頁，都會會造成大量的查詢和排序，分頁查詢需要合理的索引以及一些設計上的技巧。

MySQL效能提示8:儲存效能基線資訊，必要時才發出告警

監視和警報是必不可少的，但是典型的監視系統會發生什麼變化呢?
它開始傳送誤報，系統管理員設定了電子郵件過濾規則來阻止噪音。很快你的監控系統就完全沒用了。
（譯者注：不管是什麼問題，隨隨便便就發出告警，慢慢就麻木了，其結果是會慢慢地忽略所有的告警資訊）

我喜歡以兩種方式考慮監視:捕獲（效能）指標和警報。
捕獲並儲存所有可能的度量是非常重要的，因為當您試圖確定系統中發生了什麼變化時，您會很高興地擁有它們。
有一天，如果出現一個奇怪的問題，您會通過一個圖表並顯示伺服器工作負載變化的情況。

相比之下，人們往往過於警覺。
人們經常對諸如緩衝區命中率或每秒建立的臨時表的數量之類的事情保持警惕。
問題是，對於這樣一個比率，沒有一個好的閾值。正確的閾值不僅在不同的伺服器之間不同，而且隨著工作負載的變化也會不同。
（譯者注：很多指標並沒有一個標準值，比如建立臨時表的頻率，跟伺服器的軟硬體環境以及工作型別都有關係
如果收集了歷史的效能指標資料，遇到一些異常問題的時候，可以根據歷史性能基線與當前情況對比，提供分析問題的依據）
因此，只有在表明一個明確的、可操作的問題的情況下，才要謹慎地發出警報（不是所有問題都需要告警的，只有嚴重的問題才需要）。
低緩衝區命中率是不可隨意告警的，也不表示真正的問題，但是不響應連線請求的伺服器是需要解決的實際問題。

譯者注:正確合理的配置告警以及收集效能基線

 MySQL效能提示9:學習三種索引規則

索引可能是資料庫中最容易被誤解的話題，因為索引的工作方式有很多種，以及伺服器如何使用它們。
要真正理解索引的工作原理，需要付出很多努力。
如果設計得當，索引在資料庫伺服器中有三個重要用途:

索引允許伺服器查詢相鄰行的組，而不是單個行。
很多人認為索引的目的是找到單獨的行，但是，查詢單個行會導致隨機磁碟操作，這很緩慢。
找到一組行比一次找到一行要好得多，所有行或大部分行都很有趣。
索引可以讓伺服器避免按需要的順序讀取行來進行排序。排序是昂貴的。按需要的順序讀取行要快得多。
索引使伺服器能夠單獨滿足來自索引的所有查詢，從而完全避免訪問表。這被稱為覆蓋索引或索引查詢。

如果您可以設計索引和查詢來利用這三個機會，那麼您可以使您的查詢快幾個數量級。

譯者注:索引，一個很大的話題，很多時候需要具體情況具體分析，沒有定論，但是絕對不是網上那些low到爆的什麼索引使用1，2，3，4，5……幾條規則。

MySQL效能提示10:利用同行的專業知識

不要試圖獨自去做。如果你在苦苦思索一個問題，並且做著對你來說合乎邏輯和明智的事情，那就太好了。20次中有19次是這樣的。
另一次，你會陷入一個非常昂貴和耗時的兔子洞，因為你正在嘗試的解決方案似乎很有意義。
構建一個與mysql相關的資源網路——這超出了工具集和故障排除指南的範圍。有一些知識淵博的人潛伏在郵件列表、論壇、問答網站等等。
會議、商展和本地使用者組活動提供了寶貴的機會，可以獲得見解，並與在緊急情況下可以幫助你的同行建立關係
對於那些正在尋找補充這些技巧的工具的人，您可以檢視MySQL的Percona Configuration嚮導、MySQL的Percona Query Advisor以及Percona監視外掛。(注意:您需要建立一個Percona帳戶來訪問前兩個連結。它是免費的。)配置嚮導可以幫助您為新伺服器生成一個基線my.cnf檔案，該檔案優於隨伺服器一起釋出的示例檔案。Percona監視外掛是一組監視和繪圖外掛，可以幫助您急切地儲存統計資料，並不情願地發出警告(第8).所有這些工具都是免費的。

譯者注:學無止境，保持謙虛，永遠要向強人學習，不懂的不要瞎逼逼。