（譯）MySQL的10個基本性能技巧

原文出處：https://www.infoworld.com/article/3210905/sql/10-essential-performance-tips-for-mysql.html

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).所有這些工具都是免費的。

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