????? 有些時候，我們需要優化MySQL。那我們要對MySQL進行哪些改進呢？一條特殊的query?數據庫模式？服務器硬件？唯一的辦法是測量你的系統在做什么，在各種條件下測量它的性能。這就是我們下面要學習的。

????? 最好的策略就是找出最弱的環節，并加強你的應用程序鏈的組成。這非常有用，如果你不知道什么阻止最優性能，或者以后什么將要阻止最優性能的發揮。

????? 基準測試和剖析是兩條基本的找出瓶頸的方法。它們是有關聯的，但是它們又不完全相同。基準測試你的系統的性能。這將有助于確定系統的承受能力，向你展示哪些改變有用哪些沒用，或者顯示在不同的數據下你的應用程序的性能。

?????? 相反，剖析幫助你找出你的應用程序在哪里花費了大量的時間，或者消耗了大量的資源。換句話說，基準可以回答“這種執行表現怎么樣？”，而剖析可以回答“為什么它會這個樣子執行?”

?????? 我們準備在這個章節中講述兩部分內容，基準測試和剖析。我們開始討論基準測試的原因和對策，然后引入特定的基準測試的標桿（或者尺子）。我們先向你展示如何計劃和設計基準測試，為精確的結果做設計，執行基準測試和分析結果。最后，來看看基準測試工具和如何使用它們的例子。

?????? 剩下的章節講述如何優化應用程序和MySQL。我們將會詳細地展示我們已經應用于生產幫助分析應用程序的性能，真實的優化代碼。我們也會展示怎樣記錄MySQL的query語句，分析日志，使用MySQL的狀態計數器，以及用來查看MySQL和你的query語句怎樣做的其它工具。

為什么需要基準？

????? 很多大中型的MySQL部署有專門的標桿用在基準測試里。然而，每個開發者和DBA也應該熟悉基礎的基準測試和操作，因為它們非常有用。下面是基準測試可以幫助你的一些事情：

• ?測量你的應用程序當前是怎樣執行的。如果你不知道你的應用程序當前執行多快，你不能確定哪些改變有用。你還可以用歷史基準結果，來診斷比不能預期的問題。
• 證實你系統的可擴充性。你可以用基準測試來模仿比你的生產環境能處理的多得多的負載，比如成千上百倍的增加用戶。
• 計劃增長。基準測試能幫助你評估將來你的預計負荷需要多少硬件，網絡容量和其它資源。這能在升級或者大量應用程序改變的時候，幫助減少風險。
• 測試你的應用程序在一個變化的環境里的承受能力。例如，你可以找出你的應用程序，在并發下不定時的峰值或者不同的服務器的配置的情況下，是怎樣執行的，或者你可以看到在不同的數據分布下它是怎樣處理的。
• 測試不同的硬件、軟件和操作系統配置。對于你的系統來說，是RAID5還是RAID10更好?當你從ATA磁盤切換到SAN存儲的時候，隨機寫的性能是怎樣變化的？2.4的Linux內核比2.6的更好嗎？MySQL的升級有助于提高性能嗎？對于你的數據，不同的存儲引擎有影響嗎？你可以用不同的基準來回答這些問題。

????? 對于其他目的，你也可以用基準測試，例如，為你的應用程序創建一個單元測試套件，但是在這里我們僅僅關注性能相關方面。

??? 2.基準策略

???? 有兩條基本的基準測試策略：你可以對應用程序作為一個整體，或者隔離MySQL，用基準問題測試。這兩種策略分別以全棧和單組件基準測試聞名。有以下幾點測試整個應用程序而不僅僅是MySQL：

• 你測試整個應用程序，包括web服務，應用程序代碼和數據庫。這非常有用，因為你不僅僅關注MySQL的性能，更關心整個應用程序。
• MySQL并不總是應用的瓶頸，全站基準測試可以證明這一點。
• 只有測試整個應用，你才能知道每個部分的緩存行為。
• 基準測試在某種程度上是好的，因為它反映了你的應用的真正行為，當你單獨測試某個模塊的時候，很難發現的行為。

?? 另一方面，應用程序基準測試很難創建，甚至很難正確地安裝。如果你的基準測試設計的很糟糕，你就會得出錯誤的結論，因為結果不能反映真實情況。

?? 然而，有時你不想了解整個應用。在最初階段，可能你只想了解MySQL基準測試。下面的基準測試是有用的：

• 你想比較不同的模式或者query語句
• 你想測試應用中一個特殊的問題
• 相比長篇大論的基準測試來說，你更傾向短的基準測試，能向你展示標記和測量改變的快的“循環時間”。

??? 當你在真實數據集的環境中，一次又一次的重復你的應用query語句時，基準測試MySQL是非常有用的。數據集本身和數據集的大小都必須是真實的。如果可能的話，做一個生產環境中的數據快照。

??? 不幸的是，建立一個真實的基準，是非常復雜和耗時的；如果你能得到生產環境中的數據集的復制品，算你走運。當然，這有可能是不可行的。比如,你可能開發了一個新的應用程序，只有少數的用戶和數據。如果你想知道，如果它變得龐大時，將會有什么問題發生，除了模擬更大應用數據和負載，你沒得選擇。

??? 測試什么？

??? 在你開始基準測試之前，甚至是在你設計測試之前，你需要確定你的目標。你的目標將會決定你的工具和技術，以便得到精確地有意義的結果。用問題來設計你的目標，比如“CPU是多的好嗎？”或者“新的索引是不是比現在的索引執行的更快？”

??? 它不可能是顯而易見的，這就需要你用不同的方法來測試不同的事情，例如：延遲和吞吐量需要不同的基準測試。

??? 考慮以下幾個量度和它們如何完善你的性能目標：

?? 單位時間的交易量

????這是一個經典的歷史為基準的數據庫應用程序。標準化測試，如TPC-C標準(見http://www.tpc.org)被廣泛引用，很多數據庫提供商，工作非常努力以使它們工作的好。這些基準測試在線處理（OLTP）性能，這些基準最適合多用戶交易應用程序。通常的測量單位是每秒交易量。

??? 吞吐量這個詞通常的意思是等同于單位時間內的交易量（或者工作的其它單元）。

??? 響應時間或延遲?

??? 這測量了一個任務需要的總時間。依賴你的應用，你可能需要測量毫秒，秒或者分鐘。從這里你可以得出平均響應時間，最小響應時間和最大響應時間。

??? 最大響應時間是很少有用的度量，因為基準測試運行時間越長，可能最大響應時間越大。它并不總是能重復的，這就可能會在運行的過程中拉大差距。正是因為這個原因，很多人使用百分比的響應時間。例如，如果95%的響應時間是5毫秒，你就可以知道任務可以在總時間的95%內少于5毫秒完成。

??? 畫出基準測試的結果，為圖形或者線性圖（例如，平均值和95%百分比）或者是散列圖，將是非常有幫助的，因為這樣你就可以看到結果的分布情況。通過這些圖形，可以看出在長時間運行過程中，基準測試是怎樣執行的。

?? 假設你的系統每小時做一分鐘檢測。在檢測期間，系統“拋錨”，沒有交易完成。95%的響應時間不會顯示峰值，所以結果會掩蓋這個問題。然而，一個圖形會顯示響應時間內的周期性峰值。圖2-1會闡述這點。

?? 圖2-1顯示了每分鐘的交易量。線條顯示了象征性的超過平均值的峰值。第一個峰值是因為服務器的緩存被冷凍了，另一個峰值顯示了服務器刷新臟頁穩定性到磁盤花費的時間。如果沒有圖形我們很難看到這些差異。

???穩定性

?? 對于系統來說，穩定性測試非常重要，因為系統需要在變化的工作負載下保持性能。

?? “在一個變化的工作負載下保持性能”是一個很抽象的概念。性能是可以被度量的，例如，吞吐量和響應時間；工作負載隨著數據庫大小，當前連接數，或者硬件不同，可能會存在差異。

????穩定性測試，對于評估系統承載能力來說是好的，因為它能展示出你的應用中的薄弱環節，而在其它基準測試中不會展示。

圖2-1 30分鐘運行的結果

???? 例如，在單鏈接（不好的測試策略）的情況下做響應時間測試，你設計的系統性能良好；但是在任何等級的并發下，你應用可能會表現糟糕。一個測試關注的是在不斷增加的連接下的持續響應時間，這樣才可以看到設計的瑕疵。

???? 有一些活動，例如搜集顆粒數據創建總結性數據表的周期性批量作業，僅僅需要快速響應時間。單純地測試響應時間是好的，但是也要關心他們和其它活動是怎么交互（相互影響）的。批量作業可能會導致交互的query語句表現較差，反之亦然。

????? 并發

????? 并發是很重要的，但是很多時候都被濫用和被錯誤地衡量。例如，有一種很流行的說法，有多少用戶在同時瀏覽網站。然而，HTTP是無狀態的，大多數用戶只是簡單地閱讀瀏覽器展示的內容，所以這并不能轉化為web服務器的并發。同樣地，在web服務器上的并發并不一定轉化到數據庫服務器上。有直接關聯的就是你的會話存儲機制能處理多少數據。一個更精確的測試web服務器的并發的方法是在峰值的時候，用戶每秒請求的次數。

?????? 你也可以在應用程序的不同地方測試并發。在web服務器上的并發越高，可能引起更高的數據庫并發等級。但是語言和工具套件可能影響它。例如，Java的連接池可能會比持續連接的PHP，會降低MySQL服務器的并發連接。

????? 更重要的是在一個給定時間內運行query語句的并發數量。一個很好的設計應用程序可能會打開MySQL服務器的數以百計的并發，但是其中的一少部分應該會同時執行query語句。這樣，一個“50,000用戶同時在線”的web站點，可能在MySQL服務器上只需要10~15個同時執行query語句。

????? 換句話說，你要真正關心的基準測試就是工作并發，或者線程數量，或者同時工作連接。測試當并發增加的時候，性能掉下來多少。如果是這樣的話，你的應用程序可能就無法處理高負載下的峰值。

????? 你也需要確保性能不會很快地降下來，或者設計應用程序，這樣就不會在應用程序的各個部分產生不能處理的高并發了。在通常情況下，你要設計限制MySQL服務器的并發，如應用隊列。

????? 并發不能完全等同于響應時間和穩定性：它并不是一個結果，而是你怎樣建立基準測試的一個屬性。你應該在不同的并發水平下測試應用程序的性能，而不是測試你的應用程序的能達到的并發。

????? 總之，你應該測試對用戶來說重要的東西。測試衡量性能，但是“性能”對不同的人意味著不同的東西。收集一些關于系統應當怎樣測量的需求（正式或非正式的），能接受的響應時間，期望的并發類型，等等。然后，嘗試設計你的測試來解釋所有的需求，而不是“井底之蛙”排除其他東西關注某項東西。

????? 3.測試標桿

??????在有個大致了解的情況下，讓我們轉向怎樣設計和執行基準測試上來。在我們討論如何把基準測試做好之前，先讓我們看下一些常見的錯誤，這些錯誤能導致不能用或者不精確地結果：

• 使用真實數據大小的子集，例如，當應用程序不得不處理好幾百G的數據時，我們只使用其中的1G數據；或者當你準備擴大你的應用程序時，使用現在的數據集
• 使用錯誤的數據分布，例如當真實系統數據中的“熱點”規則的數據分布（隨機生成的數據通常是不切實際的分布）。
• 使用不切實際的分布參數，例如，假設所有用戶的配置文件同樣地被瀏覽。
• 在多用戶應用中，使用單用戶場景。
• 在單臺服務器上測試分布式應用。
• 和真實用戶的行為錯誤地比較，例如web頁面上的“思考時間”。真實用戶請求并閱讀它；他們不會一個接一個沒有停頓地點擊鏈接。
• 在一個循環里執行相同的query語句。真實的query語句是不同的，所以它們會引起緩存未命中的情況。相同的query語句將會在某種級別全部或者部分被緩存。
• 未能檢查錯誤。如果一個基準測試的結果沒有意義-例如，如果一個慢操作突然非常快地完成，那么就該檢查錯誤。你就能測試出在一個SQL查詢時，MySQL能多快地探測到語法錯誤！原則性來說，每次測試完后都應該檢查錯誤日志。
• 當系統還沒有變熱的時候，忽略系統是怎樣執行的，例如，系統剛剛重啟后。有時你需要知道你的服務器重啟后，需要多長時間達到承載能力，所以你需要在熱啟動期間注意觀察。相反地，如果你想研究它的正常性能，你需要關心，如果你的測試正好在重啟后，許多緩存將被冷凍，那么測試結果將不會反映，在緩存在變熱后，在負載下得到的結果。
• 使用默認的服務設置。

???? 僅在避免這些錯誤上就會花費你很長時間來改進你的結果質量。

???? 對于別的所有事情都是同樣的，你應該在盡可能真實的環境中做測試。盡管有時，使用一個稍微不真實的測試也是明智的。例如，假如說你的應用程序在不同的主機上。使用相同的配置執行測試，將會更接近真實情況，但是這樣做就會增加更多變量，例如，網絡負載多少，多快。在單節點上測試往往很簡單，然而在某些情況下，將會更精確。什么時候使用最合適，完全取決于你的判斷。

?????? 設計和規劃測試

?? 規劃測試的第一步就是確定問題和目標。然后，決定是否使用標準的測試還是你自己設計。

??????如果你使用標準測試，要保證你選用的測試符合你的需求。例如，不要使用TCP測試你的電子商務系統。用TCP自己的話說，TCP“”。所以對于OLTP系統來說，不是一個合適的測試。

??????設計你自己的測試是一個復雜的反復的進程。開始，使用你生產環境中的數據集的快照。確保你能為后來的運行恢復這些數據集。

??????然后，你需要在數據里運行query語句。你可以在基本測試里添加單元測試套件，多次執行，但是這和你怎樣真實地使用數據庫，不大可能匹配。一個比較好的方法是在一個典型的時間框架內，記錄你生產環境中的所有的query語句，例如，在峰值負載內的一個小時，或者一整天。如果你在很短的時間框架內，記錄了query語句，你可能需要選擇幾個時間框架。這將會使你覆蓋所有系統活動，例如，每周報告query語句，或者在低峰值的時期，執行計劃任務。

??????你可以在不同等級下記錄query語句。例如，如果你需要全棧測試的話，你就可以記錄WEB服務器上的HTTP請求。你也可以啟用MySQL的查詢日志，但是如果你重放查詢日志，要確保重新創建單獨的線程，代替線性地重放每條query語句。在日志里為每個連接創建一個單獨的線程也是非常重要的，避免線程間的query阻塞。查詢日志顯示了哪個連接執行了哪條query語句。

?????? 即使你還沒有構建自己的測試，你可以寫下你的測試計劃。你可以使測試跑很多遍，你需要重新精確地構建你的測試。也為將來打算。你可能不是下次執行這個測試的人，即使你是，你可能也不太記得你第一次是怎么執行它的。你的計劃應該包括測試數據，安裝系統的步驟和熱啟動計劃。

???? 設計一些規范參數和結果的方法，并詳細地記錄每次執行。你的文檔方法可能如電子表格或者筆記那么簡單，也可能如定做的數據庫那么復雜（但是要記住，你要寫一些腳本來幫助分析測試結果，所以沒有比打開電子表格和文本文件更容易的方法了）。

???? 你可能會發現創建一個測試目錄，包含每次執行的結果的子目錄，會很有用。在相應地的子目錄，你可以放結果，配置文件，和每次執行的筆記。如果你的測試比你預想的多，而且你也很感興趣，無論如何記錄額外的數據。錯過記錄重要的數據總比不需要的數據要好，可能以后你會發現額外數據非常有用。在測試期間盡可能多地記錄附加信息，如CPU的使用情況，磁盤I/O,和網絡流量統計;SHOW GLOBAL STATUS的計數器，等等。

?????獲得精確結果

???? 獲得精確結果的最好方法是，設計你的測試來回答你想要的問題。你有選擇正確的測試嗎？你捕捉到你需要的答案的數據了嗎？你的測試有錯誤的標準嗎？例如，你有運行一個計算密集型的測試來預測I/O密集型的應用程序的性能嗎？

???? 接著，確保你的測試結果可以重復的。盡量確保你的系統在每次開始執行的時候，是處在相同狀態的。如果測試很重要，你應當在每次執行后重啟系統。如果你需要一個預熱過的服務器，正常來講，你也應當確保你的系統已經有足夠長的預熱。例如，如果預熱過程包含了隨機query查詢，那么你的測試結果將會不可重復。

???? 如果測試改變了測試數據或數據庫模式，在每次執行的時候，用快照重新設置它。向一個表中插入一千行記錄和向一個表中插入一百萬行記錄，不會給出相同的的結果。在磁盤上的數據存儲和分布也會使結果不可重復。一個方法是確保物理布局相近，做一個快速的格式和文件拷貝分區。

???? 當心額外負載，優化和監控系統，詳細記錄日志，計劃任務，以及其它因素能使你的結果發生偏移。

?????

?

轉載于:https://www.cnblogs.com/sunss/archive/2010/09/27/1836543.html

總結

以上是生活随笔為你收集整理的找出MySQL瓶颈的基准测试和剖析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。