如何理解MySQL集群優化

這篇文章主要講解了“如何理解MySQL集群優化”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“如何理解MySQL集群優化”吧！

最近做了一個集群服務的在線切換，將原來的主從環境做了切換，當然后端的處理工作是比較復雜的，涉及到主從服務器的在線遷移和硬件變更。

總體來說，切換后的讀延遲比原本降低了0.4毫秒左右，對于一個延遲季度敏感的業務來說，0.4毫秒是一個很高的比例，按照既定的比例規則，差不多是優化了25-30%的比例。

那么這省下來的0.4毫秒到底優化在哪個環節了呢?我們做了一些討論和分析，不僅暗暗感嘆，幸虧是優化了，如果延遲變大30%，要快速分析還是壓力很大的。

這個問題分析的難點在于存在一系列的動態變量，導致服務切換前后的對比缺少了一些基準和衡量標準。

我們簡單提煉了下，在服務切換前的優化工作有：

1)新從庫采用了全新的硬件配置，CPU型號更高，性能提升可達30%

2)主從庫采用的SATA-SSD的存儲使用了不同品牌

3)主從切換前，在從庫中對數據表進行了全面的碎片清理

4)原本服務器的系統盤是使用SAS的，在新從庫中統一按照SATA-SSD類配置

5)中間件服務器有近2年沒有重啟過，這次維護做了重啟維護

此外，還有一些不確定的因素，比如業務量的差異等，按照100%對等的標準是不大可能完全對等去分析的，所以我們試著通過如下的邏輯進行分析。

初步來看，我們覺得對于數據表做了碎片清理，這個改進的效果會比較高，因為碎片率在切換前統計是近20%，清理后空間釋放了近20%，本來認為這樣的一套指標體系是比較演進的，但是在對比了近幾天的業務延遲情況之后，有一個業務的數據是說不通的。

我們假設是業務2，業務2的數據表示日表，也就意味著這張表沒有所謂的碎片，因為每天都會有一張新的數據表寫入數據。所以業務2的延遲應該沒有變化或者有細小的差異才說得通，但是在這里可以很清楚的看到，延遲是有近30%的提升，這就說不通了，所以單純的碎片清理帶來的收益確實沒有期望那么高。

我們分析下系統負載的情況，隨機選擇了一個分片節點，查看了切換前和切換后的負載數據。

切換前

切換后

總體來說，負載的平均值是提高了0.03，這個比例是很低的一個比例，姑且認為是可以忽略的。

再來看看CPU的使用率，因為新的服務器CPU性能提升近30%，所以對負載情況進行了整體的比對，可以發現這個業務不是強計算相關的，所以CPU配置再好，在這里帶來的收益確實沒有期望那么明顯。

切換后

切換前

接著來看磁盤，磁盤層面有很多的指標，我們來看下util指標：

切換后：

切換前：

總體切換后的util從16%提高到了18%，很難可以給出一個客觀的結論。

對于磁盤讀寫層面的分析，可以看到等待的延遲部分不是一個數量級。

切換后

切換前

在這里可能會有一個誤區，那就是切換前的指標是精確度不夠，是0，我們可把指標放大，即選擇其中一個指標，就可以看到右側的指標的相對精確的數據了。

切換后：

切換前：

到了這里，我們可以看到延遲的指標對于邏輯卷和不同分區的差別還是很明顯的，雖然單個指標的提升在10%左右，但是所有的指標都是略高一籌。

當然碎片整理確實是有提高，但是和磁盤層面的提升來說，占比確實沒有那么高。

而接下來的問題就是進一步驗證，需要分析不同SSD產品間的一些差異和穩定性測試數據。

總體來說，整個分析的過程可以提供一種分析的思路，而不僅僅是得到的初步結論。

感謝各位的閱讀，以上就是“如何理解MySQL集群優化”的內容了，經過本文的學習后，相信大家對如何理解MySQL集群優化這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！