MySQL 查詢語句可以分為 Server 層和存儲引擎層。而 Server 層包括連接器、查詢緩存、解析器、預處理器、優(yōu)化器、執(zhí)行器等，

最后 Server 層再通過 API 接口形式調用對應的存儲引擎層提供的接口來執(zhí)行增刪改查操作。

如下圖所示：

?

1、介紹

關于sql語句在執(zhí)行過程中，可能會涉及到以下的組件來進行相互的調用。

1.1、組件介紹

組件及其作用，可參考：

1.2、Sql執(zhí)行順序

在 SQL 中，select語句的語法結構看似是按照關鍵字書寫順序執(zhí)行的（如select ... from ... where ...），但實際執(zhí)行順序與語法順序并不完全一致。

如下圖所示：

注意：

在包含子查詢的 SQL 中，子查詢本身也是一個完整的select語句，其內部仍然遵循上述執(zhí)行順序。外部查詢的執(zhí)行順序會以子查詢的最終結果為輸入繼續(xù)執(zhí)行。

為了更好地理解這個順序，我們可以從“數(shù)據(jù)流”的角度思考：

• FROM：首先確定從哪個表或視圖中讀取數(shù)據(jù)。
• WHERE：在獲取原始數(shù)據(jù)后，先進行行級過濾，減少后續(xù)處理的數(shù)據(jù)量。
• GROUP BY：將過濾后的數(shù)據(jù)按指定字段分組，為聚合操作做準備。
• HAVING：在分組后，進一步過濾不滿足條件的組。
• SELECT：確定最終返回的字段（包括常量、表達式、聚合函數(shù)等）。
• ORDER BY：對最終結果進行排序。
• LIMIT：限制返回的記錄數(shù)量。

如下圖所示：

2、執(zhí)行流程

一個完整的執(zhí)行流程包括以下組件，連接器、緩存、解析器、優(yōu)化器、執(zhí)行器和存儲引擎組成。

如下圖所示：

2.1. 連接與認證

MySQL 服務端和客戶端的通信方式采用的是半雙工協(xié)議。

客戶端連接：客戶端通過協(xié)議（如 TCP/IP、Socket）與 MySQL 服務端建立連接。

認證：服務端驗證用戶身份（用戶名、密碼、權限）。如果驗證失敗，連接終止。

權限檢查：確認用戶是否有權限執(zhí)行當前查詢（如 SELECT 權限）。

常見的通信方式主要可以分為三種：單工，半雙工，全雙工。

單工：

通信的時候，數(shù)據(jù)只能單向傳輸。比如說遙控器，我們只能用遙控器來控制電視機，而不能用電視機來控制遙控器。

半雙工：

通信的時候，數(shù)據(jù)可以雙向傳輸，但是同一時間只能有一臺服務器在發(fā)送數(shù)據(jù)，當 A 給 B 發(fā)送數(shù)據(jù)的時候，那么 B 就不能給 A
發(fā)送數(shù)據(jù)，必須等到 A 發(fā)送結束之后，B 才能給 A 發(fā)送數(shù)據(jù)。比如說對講機。

全雙工：

通信的時候，數(shù)據(jù)可以雙向傳輸，并且可以同時傳輸。比如說我們打電話或者用通信軟件進行語音和視頻通話等。

半雙工協(xié)議讓 MySQL 通信簡單快速，但是也在一定程度上限制了 MySQL 的性能，因為一旦從一端開始發(fā)送數(shù)據(jù)，另一端必須要接收完全部數(shù)據(jù)才能做出響應。

所以當批量插入的時候盡量拆分成多次插入而不要一次插入太大數(shù)據(jù)，同樣的查詢語句最好也帶上 limit 限制條數(shù)，避免一次返回過多數(shù)據(jù)。

MySQL 單次傳輸數(shù)據(jù)包的大小可以通過變量 max_allowed_packet 控制，默認大小為 64MB（5.7 版本默認只有 4MB）。

執(zhí)行以下語句查看 max_allowed_packet 變量大?。?/p>

2.2. 查詢緩存

緩存命中檢查：

如果開啟了查詢緩存（Query Cache），MySQL 會直接檢查是否有完全相同的查詢結果緩存。

命中：直接返回緩存結果。

未命中：進入后續(xù)流程，并可能將結果寫入緩存（取決于配置）。

注意：MySQL 8.0 已移除查詢緩存功能。

移除原因：

因為 MySQL 的緩存使用條件非?？量?，是通過一個大小寫敏感的哈希值去匹配的，這樣就是說一條查詢語句哪怕只是有一個空格不一致，都會導致無法使用緩存。而且一旦表里面有一行數(shù)據(jù)變動了，那么關于這種表的所有緩存都會失效，所以一般我們都是不建議使用緩存。

在 MySQL 8.0 版本之前緩存也是默認關閉的，可以通過變量 query_cache_type 進行控制。

2.3. 語法解析（Parser）

詞法分析：將 SQL 語句拆分為 token（如關鍵字、標識符、操作符等）。

語法分析：根據(jù) SQL 語法樹規(guī)則，檢查語句合法性（如SELECT * FROM table是否符合語法）。

生成抽象語法樹（AST）：將 SQL 轉換為數(shù)據(jù)庫可理解的內部結構。

整個sql語句會被分割成：select,name,from,table,where,id,=,1這幾個字符。并且能識別出關鍵字和非關鍵字，然后根據(jù) sql 語句生成一個數(shù)據(jù)結構，也叫做解析樹。

如下圖所示：

2.4、執(zhí)行sql

如下圖所示：

1. 預處理（Preprocessor）

語義檢查：

• 檢查表、列是否存在。
• 驗證權限（如用戶是否有權限訪問指定的表或列）。
• 替換別名、處理函數(shù)等。

生成邏輯查詢計劃：

• 將 AST 轉換為邏輯執(zhí)行計劃（如select a from t1 where b = 5）。

2. 查詢優(yōu)化器（Optimizer）

其目標是生成最優(yōu)的執(zhí)行計劃（即最小資源消耗、最快響應時間）。

優(yōu)化步驟：

選擇訪問路徑：決定是否使用索引（如全表掃描 vs 索引掃描）。如果有多個索引，選擇最合適的索引。

連接順序優(yōu)化（針對多表查詢）：決定表的連接順序（如 A JOIN B JOIN C 的順序）。使用動態(tài)規(guī)劃或代價模型（Cost Model）計算最優(yōu)順序。

其他優(yōu)化：優(yōu)化子查詢（如轉換為 JOIN）。優(yōu)化排序（ORDER BY）和分組（GROUP BY）。常量傳播、條件簡化等。

輸出執(zhí)行計劃：生成物理執(zhí)行計劃（如使用哪個索引、連接算法等）。

3. 執(zhí)行器（Executor）

執(zhí)行查詢計劃：

• 調用存儲引擎接口（如 InnoDB、MyISAM）獲取數(shù)據(jù)。
• 根據(jù)執(zhí)行計劃逐層處理（如過濾、排序、分組）。

權限二次檢查：

• 確保用戶對訪問的數(shù)據(jù)有權限。

數(shù)據(jù)處理：

• 讀取數(shù)據(jù)行（通過全表掃描或索引掃描）。
• 應用 WHERE 條件過濾。
• 對結果進行排序、分組、聚合等操作。

2.5. 存儲引擎交互

存儲引擎接口：

• MySQL 通過統(tǒng)一的接口（Handler API）與存儲引擎交互。

InnoDB 的處理：

• 通過 B+ 樹索引定位數(shù)據(jù)。
• 處理事務（如鎖機制、MVCC）。
• 返回符合條件的記錄。

其他引擎：

• 如 MyISAM 的處理方式不同（無事務支持）。

2.6. 返回結果

結果集組裝：

• 將處理后的數(shù)據(jù)按用戶指定的格式（如 SELECT 字段）組裝。

分頁處理：

• 若涉及 LIMIT 或分頁，截取對應的數(shù)據(jù)。

返回客戶端：

• 一次性返回（小結果集）。
• 流式返回（大結果集，通過網(wǎng)絡分批次傳輸）。

MySQL 將查詢結果返回是一個增量的逐步返回過程。

當處理完所有查詢邏輯并開始執(zhí)行查詢并且生成第一條結果數(shù)據(jù)的時候，MySQL 就可以開始逐步的向客戶端傳輸數(shù)據(jù)了。這么做的好處是服務端無需存儲太多結果，從而減少內存消耗。

3、示例流程（SELECT 查詢）

以SELECT * FROM users WHERE id = 1;為例：

• 客戶端連接數(shù)據(jù)庫。
• 檢查查詢緩存（未命中）。
• 解析 SQL 語法，生成 AST。
• 預處理：檢查users表和id列是否存在。
• 優(yōu)化器選擇id索引進行查找。
• 執(zhí)行器調用 InnoDB 引擎，通過索引定位到id=1的記錄。
• 返回結果給客戶端。

4、常見問題與優(yōu)化

• 慢查詢：檢查執(zhí)行計劃（使用EXPLAIN），優(yōu)化索引或調整查詢邏輯。
• 全表掃描：添加合適的索引或優(yōu)化查詢條件。
• JOIN 性能：調整連接順序或使用索引。
• 緩存失效：頻繁更新的表可能導致緩存命中率低（MySQL 8.0 后不再依賴此）。

總結

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論