【51CTO精選譯文】MySQL集群是一款實時、可擴展的事務性數據庫。其設計初衷在于為對實時性能要求較高的應用程序打造一套嵌入式電信數據庫，并實現運營商級別的可用性。不過MySQL集群也可以通過擴展實現諸多企業級解決方案，例如移動支付系統、實時分析、數據流與分析以及內容管理等事務。MySQL集群的橫向擴展能力足以滿足密集型工作負載的需求，其集群架構如下圖所示：

整信集群由三類節點構成：數據節點、應用程序節點以及管理節點。

• 數據節點通常負責數據訪問與存儲事務。
• 應用程序節點提供由應用程序邏輯層及應用API指向數據節點的鏈接。
• 管理節點在集群配置體系中的作用至關重要，并在網絡分區環境下負責負載指派。

在本文中，我們將共同探討提升MySQL集群性能的***實踐方案。通過這些方案，大家將能在各類工作負載中實現游刃有余的資源分配效果。

最適合MySQL集群的應用程序

MySQL集群能確保來自應用程序或者SQL節點的更新立即被用于集群體系中的每一個節點。表格被劃分至一系列商用節點當中，從而實現數據庫的橫向可擴展性。

MYSQL集群在數據庫層處理表格劃分，這就避免了對應用程序層的影響。這一特性能夠大大簡化應用程序的開發與維護工作。在事務性工作負載方面，MySQL集群還能提供非常強大的數據吞吐能力。另外，這套集群可以利用多個并行SQL節點，且每個節點都提供多個連接。

最適合MySQL集群的應用程序包括：

• 交易平臺/系統；
• 支付網關；
• 用戶配置管理；
• 多人網絡游戲；
• IMS服務；
• DHCP寬帶接入；
• VoIP及視頻會議。

識別性能問題

我們一直建議大家對延遲及事務數據吞吐量等性能指標進行重復檢測方針。另一大關注重點在于考量數據庫的特定變更及其可用性。大家應該在變更實際部署前進行性能測試，并在優化技術安置完畢后再次進行測試。

在某些情況下，我們可能無意中遇上必須滿足的特殊需求。通過迭代流程，大家可以追蹤目標的當前進展。除了檢測應用程序的整體性能，大家還應該考慮個別事務的性能表現。某些查詢請求可能需要很長時間才能執行完畢。

如果大家利用SQL對接入MySQL Enterprise Monitor的數據庫進行查詢，那么不妨試試Query Analyzer--它能追蹤所有負載較高的事務。如果大家沒有接入Enterprise Monitor，那么MySQL慢速查詢日志也足以幫助我們找出處理過程過長的事務。我們可以通過對long_query_time變量的設定選擇日志中到底應該保留哪些慢速查詢（即慢到何種程度）。變量數值的單位是"秒"，將該數值設為"0"則代表在日志中記錄下所有查詢請求。

由于對long_query_time變量所做出的變更不會馬上體現在活動連接當中，因此大家需要刪除當前連接然后重新建立。

MySQL集群在數據節點內保留著全部細節信息。這部分數據可由名為NDBINFO的虛擬數據庫直接使用。舉例來說，NDBINFO能夠顯示磁盤頁面緩沖區的使用信息。所謂磁盤頁面緩沖區，其實是各個數據節點根據表格進行磁盤操作時的緩存。通常情況下，其緩沖命中率越高、則性能表現越好。調整這部分緩存的大小會對系統產生顯著影響。大家可以通過mysql命令行訪問磁盤頁面緩沖數據。#p#

性能優化

訪問模式

要想讓MySQL集群部署發揮出與預期相符的性能，最重要的一點在于了解數據庫結構。有一點需要注意--MySQL集群表格中的數據并不會被保存在MySQL服務器當中。這些數據實際上被劃分至由多個數據節點構成的資源池當中，如下圖所示。

表格中的各行將被拆分成多個區塊，每個數據節點保留一個區塊的主片段及另一個區塊的次片段。

如果查詢需要多次網絡跳轉，例如由服務器向數據節點或者在不同數據節點之間，那么性能與可擴展性都可能受到影響。因此，要想讓MySQL集群獲得***性能表現，我們必須盡量減少網絡跳轉次數。表格劃分基于主鍵散列，但我們可以對其進行重寫以提高性能。簡單的訪問模式是創建可擴展且高性能解決方案的關鍵。

網絡跳轉的必要次數取決于來自各分支結構的結果集與接合深度。如果表格的接合深度過大，那么指向數據節點的每一次跳轉也將耗費更多時間。要想獲得***性能，我們需要利用主鍵查找--其完成時間是恒定的，與數據庫規模及數據節點數目沒有關系。

使用AQL

通過使用AQL（即適應性查詢本地化），性能改善將體現得更為明顯。

AQL能夠將查詢由MySQL服務器指派向全部數據節點，且查詢由本地數據副本負責執行。然后它會向MySQL服務器發回合并結果集，從而最終實現減少網絡跳轉、提高性能表現的目的。

AQ能幫助MySQL集群高效處理涉及大量復雜查詢事務的用例。

為了獲得更理想的使用效果，大家可以在變更表格模式（包括添加、刪除索引或者執行其它重要變更）后在某一臺MySQL服務器中運行OPTIMIZE TABLE <tab-name>。

在實際使用環境中的測試結果顯示，AQL能夠將大量查詢事務的整體效率提升70倍。在測試中，一套網絡內容存儲管理系統中包含有十一套復雜表格，在對其進行正常查詢時，整個流程需要耗時87秒。但在AQL的幫助下，整個流程的時耗被直接縮短至1.26秒。

在默認情況下，AQL受到全局變量ndb_join_pushdown的控制。為了能夠讓AQL切實起效，我們需要對其進行如下規則修改：

• 要加入的列必須使用同一種數據類型，包括VARCHAR長度列在內。
• 無法對指向BLOB或TEXT列的連接起效。
• 不支持顯式封鎖，但我們可以通過基于NDB存儲引擎鎖定的隱式行實現同等效果。
• 無法對明顯由HASH或者RANGE進行劃分的連接起效。

分布感知應用

在利用MySQL集群向表格中添加行時，每一行都歸屬于一個分區。每個分區又都由集群中的一個特定數據節點所掌控。只有事務需要的全部數據都被劃分到同一個分區當中時，集群性能才能實現***。這意味著我們要利用一個單獨數據節點來取消在多個節點之間往復傳輸所帶來的延遲提升。

MySQL集群默認通過主鍵散列對數據進行劃分。我們可以指定主鍵中的特定字段并將其提交給散列算法，從而改變默認方案。

大家也可以利用分區裁剪方案。分區裁剪流程是指通過單一數據節點進行索引掃描，其延遲改善效果取決于數據節點的數量及結果集的大小。數據節點越多、需要取回的記錄越少，改進的效果也就越好。

下圖顯示了分區裁剪對性能的提升情況。

分區裁剪能夠有效降低小型結果集的延遲狀況，但對較大的結果集而言反倒會提高延遲表現。上圖中的紅色條形代表分區裁剪后的延遲數字。

在這種情況下，應用程序分布機制對于新增額外節點的識別能力就成了保證性能改善的關鍵。

使用連接池

MySQL集群在多個數據節點進行大量并行操作時的吞吐能力***。有鑒于此，我們必須同時利用多臺MySQL服務器且應用程序的各個線程全部接入這些服務器。要訪問數據節點，mysqld進程會默認使用單獨的NDB API連接。由于大量應用程序線程同時搶占這一條連接，我們需要設置一套互斥機制以避免吞吐操作發生沖突。

一種方案是讓每個應用線程都使用其專用的mysqld進程，但這不僅浪費資源、同時也會增加應用程序的復雜性。

更為高效的方案是如上圖所示，建立由mysqld進程向數據節點的多條NDB API連接。

為了使用連接池，每條（來自mysqld）連接都需要在config.ini文件中擁有自己的[mysqld]或者[api]分節號，然后在my.cnf文件中將ndbcluster-connection-pool值設置為大于1。另外，我們也絕不能在啟動mysqld進程的同時將ndb-node-ida作為命令行選項。在我們的測試實例中，單一mysqld進程擁有四個NDB API連接。

上圖顯示了連接池所帶來的性能提升。一般來說，應用程序的性能普遍能獲得70%的提升，但在某些特殊情況下、其提升幅度可能超過150%。

添加節點以實現擴展

MySQL集群在設計思路中納入了橫向擴展考量。能夠添加額外的MySQL服務器或者數據節點，大家可以顯著提升整體性能。

我們還能夠向處于運行狀態的MySQL集群中添加新的MySQL服務器或者節點組。也就是說，我們完全不必關機并重新加載集群。現有表格中的數據將被重新劃分到所有接入數據節點當中。最安全的處理方式是使用MySQL Cluster Manager。這款集群管理器能自動處理關于額外節點添加的所有事務，而且我們不必擔心整個過程會造成任何服務丟失。

總結

在過去九年中（自2004年起），MySQL集群已經逐步成為一款成熟的解決方案，能夠滿足極端性能水平要求以及高達99.99%的嚴格正常運行標準。正如在文章開頭所說，自適應查詢本地化、參數調整以及分布感知等特性令MySQL集群在性能方面更上一層樓，從而有能力服務于更廣泛的應用組合方案。作為數據庫技術的核心要素，實時監控與報告功能的強化也幫助數據庫開發人員及管理員們得以更好地在MySQl集群中擴展自己的用例。

原文鏈接：

http://www.agileload.com/agileload/blog/2013/03/11/optimizing-the-performance-of-mysql-cluster