MySQL中如何理解基于多個維度分析服務器性能

這篇文章給大家介紹MySQL中如何理解基于多個維度分析服務器性能，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

一、服務器性能簡介

1、性能定義

服務器性能優化是一項非常艱巨的任務，當然也是很難處理的問題，在寫這篇文章的時候，特意請教下運維大佬，硬件工程師，數據庫管理，單從自己的實際開發經驗來看，看待這個問題的角度起碼是不全面的。

補刀一句：在公司靠譜少撕逼，工程師這個群體是很好交朋友的，互相學習一起進步，升職加薪他不好嗎？

服務性能定義：完成一個任務或者處理一次接口請求所需要的時間，這個時間是指響應完成時間，即請求發出，到頁面響應回顯結束，這是看待性能問題的基本邏輯。

2、分析性能

服務的基本過程一般如下圖，這是一張最簡單的前后端分離，加一臺數據庫存儲的流程，但是想要說明一個復雜的邏輯。

從頁面請求，到獲取完整的響應結果，這個過程每個環節都可能導致性能問題，拋開網絡，硬件，服務器，MySQL存儲這些核心客觀因素，單是下面這行代碼就可以秒掉很多人的努力。

Thread.sleep(10000); // 仿佛整個世界都安靜了。

影響性能的因素很多，一般說性能優化會從下面幾個方面考慮：

• 網絡傳輸，比如私有云和公有云的交互，接口傳輸內容過大；

• 應用服務，接口設計是否最簡，沒有邏輯問題，架構設計是否合理；

• 存儲服務，MySQL的查詢寫入，表設計是否合理，連接池配置是否合理；

• 硬件設施，CPU和內存的利用是否在合理區間，緩存是否合理；

這些問題每個處理起來都是非常耗費時間，且對人員的要求相對較高，不說一定要到達專家水平，起碼性能問題出現時候，基本的意識要有。

二、MySQL執行機制

基于上述流程圖，MySQL性能分析主要從下面幾個方面切入，基本方向就不會偏。

1、連接池配置

查看默認最大連接數配置：

SHOW VARIABLES LIKE 'max_connections';

最小連接數是連接池一直保持的會話連接，這個值相對好處理許多，評估服務在正常狀態下需要多少會話連接。

最大連接數服務器允許的最大連接數值，這個參數的設計就比較飄逸，需要對高并發業務有把控，且要分析SQL性能，和CPU利用率（基本上是70%-85%），想獲得這一組參數，可是相當不容易，需要測試精細，配合運維進行服務監控記錄，開發不斷優化，可能要分庫分表，或者集群，拆服務分布式化等一系列操作，最終才能得到合理處理邏輯，當然這樣費心對待的都是核心業務，一般的業務也就是經驗上把控。

2、SQL執行過程

MySQL解析器識別SQL的基本語法，生成語法樹，然后優化器輸出SQL可執行計劃，非常復雜的流程。

• 客戶端發送請求到MySQL服務器；

• 如果執行查詢，會檢查緩存是否命中；

• 服務端進行SQL解析，預處理，最后優化器生成執行計劃；

• 根據執行計劃調用存儲引擎API執行；

• 返回客戶端處理結果；

補刀一句：這也就是為什么現在接口提倡最簡化設計，或者接口拆分，分步執行，不要問這樣會不會多次請求，給網絡造成壓力，這都5G時代了。

3、邏輯總結

總結一句話：分析是否存在MySQL服務的性能問題，需要考量是不是服務配置問題，或者SQL編譯過程問題，導致大量等待時間，還是SQL執行有問題，或者查詢數據量過大導致執行過程漫長。

補刀一句：MySQL性能問題的基本原因很簡單，數據量不斷變大，服務器承載不住。作為開發，這是面對數據庫優化的根本原因。

三、執行語句分析

1、基本描述

上面幾個方面都是在說明面對服務性能問題時，意識上要清楚的邊界，作為開發實際上要面對兩個直接問題：表設計，SQL語句編寫，大部分的開發都被這兩個問題毒打過。

2、表結構設計

表設計：表設計關系到數據庫的各個方面知識：數據類型選擇，索引結構，編碼，存儲引擎等。是一個很大的命題，不過也遵循一個基本規范：三范式。

規范的表結構，合適的數據類型可以降低資源的占用，索引可以提高查詢效率，存儲引擎更是關系到事務方面的問題。

表的結構的邏輯清晰，是后續查詢和寫入的基本條件，結構過大，會出現很多索引，分表結構多，帶來很多連接查詢，同樣會把開發感覺按在地上。這就涉及到一個玄學：開發要根據經驗和因素，權衡表結構設計。

補刀一句：如果你去問3.5年的開發，最想寫什么業務，他肯定會說單表的增刪改查，為什么？因為這類任務是不會排期給他的。

3、數據更新

假設在表結構符合邏輯的情況下，數據更新(增刪改)操作一般情況下不會出現較大問題，遵循幾個基本原則。

• 數據量大的寫入，執行批量操作，占用連接少；

• 刪除和更新要考慮鎖定的粒度，不要導致大范圍鎖定；

• 經常執行刪除操作，要考慮內存碎片問題；

• 批量操作可以基于應用層面使用多線程處理；

4、數據查詢

查詢是開發中最常面對的問題，針對查詢的規范也是特別多，確實查詢也是最容易出錯的環節。但是影響查詢的因素很多，可能很多情況下查詢只是背黑鍋：

• 表設計規范，減少各種關聯，子查詢；

• 列類型規范，數據值規范，Null和空處理；

• 索引結構和使用規范，對查詢性能影響最大；

• 存儲引擎選擇合適，直接影響鎖定粒度大小；

• 外鍵關聯導致表強行耦合，最討厭的一個功能；

SQL在執行的時候，如果性能很差，還需要基于MySQL慢查詢機制進行分析，查看是否出現磁盤IO，臨時表，索引失效等各種問題。

四、模塊總結

上述的描述可能感覺有點亂，但是整體上看，就分為下面三個模塊：

• 應用服務流程化分析，判斷瓶頸出現環節；

• 熟悉MySQL基本機制，分析等待和執行時間；

• MySQL的表結構設計和SQL執行優化；

這篇文章只是籠統描述一下服務性能的問題，重點還是想陳述一個基本邏輯：具備服務性能問題分析的意識，且意識的邊界相對全面，不要只盯著某個方面思考。

補刀一句：因為文章的分類是MySQL模塊，所以重點的描述也在MySQL層面。實際情況中，任何層面都可能導致性能問題。

五、源代碼地址

GitHub·地址
https://github.com/cicadasmile/mysql-data-base
GitEE·地址
https://gitee.com/cicadasmile/mysql-data-base

推薦閱讀：

MySQL數據庫基礎

關于MySQL中如何理解基于多個維度分析服務器性能就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。