本文原始碼：[GitHub·點這裡](https://github.com/cicadasmile/mysql-data-base) || [GitEE·點這裡](https://gitee.com/cicadasmile/mysql-data-base) # 一、伺服器效能簡介 ## 1、效能定義 伺服器效能優化是一項非常艱鉅的任務，當然也是很難處理的問題，在寫這篇文章的時候，特意請教下運維大佬，硬體工程師，資料庫管理，單從自己的實際開發經驗來看，看待這個問題的角度起碼是不全面的。 `補刀一句`：在公司靠譜少撕逼，工程師這個群體是很好交朋友的，互相學習一起進步，升職加薪他不好嗎？ 服務效能定義：完成一個任務或者處理一次介面請求所需要的時間，這個時間是指響應完成時間，即請求發出，到頁面響應回顯結束，這是看待效能問題的基本邏輯。 ## 2、分析效能 服務的基本過程一般如下圖，這是一張最簡單的前後端分離，加一臺資料庫儲存的流程，但是想要說明一個複雜的邏輯。  從頁面請求，到獲取完整的響應結果，這個過程每個環節都可能導致效能問題，拋開網路，硬體，伺服器，MySQL儲存這些核心客觀因素，單是下面這行程式碼就可以秒掉很多人的努力。 ``` Thread.sleep(10000); // 彷彿整個世界都安靜了。 ``` 影響效能的因素很多，一般說效能優化會從下面幾個方面考慮： - 網路傳輸，比如私有云和公有云的互動，介面傳輸內容過大； - 應用服務，介面設計是否最簡，沒有邏輯問題，架構設計是否合理； - 儲存服務，MySQL的查詢寫入，表設計是否合理，連線池配置是否合理； - 硬體設施，CPU和記憶體的利用是否在合理區間，快取是否合理； 這些問題每個處理起來都是非常耗費時間，且對人員的要求相對較高，不說一定要到達專家水平，起碼效能問題出現時候，基本的意識要有。 # 二、MySQL執行機制 基於上述流程圖，MySQL效能分析主要從下面幾個方面切入，基本方向就不會偏。 ## 1、連線池配置 檢視預設最大連線數配置： ```sql 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資料庫基礎** |序號|文章標題| |:---:|:---| |01|[MySQL基礎：經典實用查詢案例，總結整理](https://mp.weixin.qq.com/s/1LHqN2V_NvhL9ky8f8qoZw)| |02|[MySQL基礎：從五個維度出發，審視表結構設計](https://mp.weixin.qq.com/s/J_kDdyxKlQyT00e7-Uu0lQ)| |03|[MySQL基礎：系統和自定義函式總結，觸發器使用詳解](https://mp.weixin.qq.com/s/-MsW3f-Vhsmij2nwtgDTvw)| |04|[MySQL基礎：儲存過程和檢視，用法和特性詳解](https://mp.weixin.qq.com/s/x8Pm1nH2WwsWFFnOYMo9gw)| |05|[MySQL基礎：邏輯架構圖解和InnoDB儲存引擎詳解](https://mp.weixin.qq.com/s/I0B8I4LOGbG-caGIc6NwLQ)| |06|[MySQL基礎：事務管理，鎖機制案例詳解](https://mp.weixin.qq.com/s/eja7F25A4ubBNre282u-jg)| |07|[MySQL基礎：使用者和許可權管理，日誌體系簡介](https://mp.weixin.qq.com/s/6qz0WQ-MHzk37SMf6