（譯）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).全部這些工具都是免費的。 譯者注:學無止境，保持謙虛，永遠要向強人學習，不懂的不要瞎逼逼。