“我平時的工作就是 CRUD (增刪改查)呀！我怎麼提升自己的技術？“、”平時開發我都是用開源的 MyBatis、Hibernate，連原生的 sql 我都沒寫過幾行”、“SQL 調優除了加索引，我也沒有什麼特別的手段去優化了”。

相信這樣的問題你可能也會遇到，但是，這種低水平重複工作做多了後，不免要擔心一點：我們要如何才能打破這種僵局，進一步提升自己的技術呢？

從本節起，我們先從與 CRUD 密不可分的資料庫開始講起。MySQL 相信你並不陌生，它已成為多年來最流行的開源資料庫。所以，我們將針對 MySQL 展開資料庫領域的進階提升，不再只滿足於寫簡單的 SQL。

本節我們就來 MySQL 的基礎架構。

邏輯架構圖——“千呼萬喚始出來”

首先，讓我們來一起看一起 MySQL 的邏輯架構圖，如下：

從圖中可以看出，MySQL 可以分為「Server 層」和「儲存引擎層」。

為了更好地理解其中的細節，我們來看一下更加具體的邏輯架構。

注：該圖片來自於網路，後面文章中如果已有不錯的圖片，我就不再重複“造輪子”。圖侵刪。

結合圖片，我們簡單解釋一下各部分的作用：

• 最上層：客戶端。大多數基於網路的客戶端/服務端服務都有類似的架構。

  如連線處理、授權認證、安全等。

• 第二層：核心服務功能。對應圖中「聯結器分析器、優化器、執行器、查詢快取」。

  包含內建函式（如日期、時間、數學函式等）、跨儲存引擎功能如儲存過程、觸發器、檢視

  等。

• 第三層：儲存引擎。負責資料的儲存和提取。其架構是外掛式的，支援 InnoDB、MyISAM、Memory等多個儲存引擎。

  具體實現：伺服器通過 API 與儲存引擎通訊，不同儲存引擎不會互相通訊，只是簡單響應伺服器請求。

  從 MySQL 5.5.5 開始，InnoDB 成為了預設的儲存引擎。

這裡我想補充一點，MySQL 最重要的特性就是「儲存引擎架構」。

它的優點非常突出，可以將查詢處理及其他系統任務和資料的儲存/提取相分離，即「處理和儲存分離設計」。

• 啟發一： plugin 這種可插拔式的設計給予了 MySQL 儲存引擎非常大的靈活性。
• 啟發二：儲存與計算分離也是當下熱門的趨勢，如
  Apache Pulsar。

一條 SQL 的“奇幻漂流”

接下來，我們通過一條 SQL，跟隨著它的“奇幻漂流”，來逐一認識一下看看架構圖中的不同部分。

為了有個直觀的感覺，我們就假設要執行的 SQL 為： select * from T where id=1;。

聯結器

第一步，我們要先連線到這個資料庫上。

聯結器的主要作用：負責和客戶端建立連線、獲取許可權、維持和管理連線。

常見的命令一般為：

mysql -h$ip -P$port -u$user -p

輸完命令之後，你就需要在互動對話裡面輸入密碼。

這裡我想提醒一下：如果使用者名稱密碼認證通過，聯結器會去許可權表中查詢使用者的所有許可權。之後，這個連線的許可權都依賴於此時讀到的許可權。也就是說，即使中途使用者許可權變更，也不會影響已經存在連線的許可權。（只有新建的連線才使用新許可權）

show processlist

連線完成後，如果沒有後續操作，這個連線就處於空閒狀態。可以用 show processlist 命令中看到它。下圖就是執行結果，其中 Command 列顯示為“Sleep”的這一行，就表示當前系統裡有一個空閒連線。

如果客戶端太長時間沒有動靜，聯結器就會自動斷開連線。這個時間是由引數wait_timeout控制的，預設值是8小時。

如果你之前應用中用到了 MySQL，可能就會遇到過在日誌中有時空閒太長，應用與 MySQL 的連線斷開的情況，這就是根源所在。

連線被斷開之後，客戶端再次傳送請求，就會收到一個錯誤提醒： Lost connection to MySQL server during query。如果你要繼續請求，就需要重連。

「長連線」和「短連線」

• 長連線：連線成功後，如果客戶端持續請求，一直使用同一個連線。

• 短連線：每次執行完很少的幾次查詢就斷開連線，下次查詢再新建一個。

因為建立連線的過程比較複雜，建議你儘量使用長連線。

但全部使用長連線後，你可能會發現，有時 MySQL 佔用記憶體漲得特別快，因為MySQL在執行過程中臨時使用的記憶體是管理在連線物件裡面的。這些資源只有在連線斷開時才會釋放。所以如果長連線累積下來，可能導致記憶體佔用太大，被系統強行殺掉（OOM），從現象看就是 MySQL 異常重啟。

怎麼解決這個問題呢？你可以考慮以下兩種方案：

• 定期斷開長連線。

  使用一段時間，或者程式裡面判斷執行過一個佔用記憶體的大查詢後，斷開連線，之後要查詢再重連。

• 如果你用的是MySQL 5.7或更新版本，可以在每次執行一個比較大的操作後，執行 mysql_reset_connection 重新初始化連線資源。

  這個過程不需要重連和重新做許可權驗證，但是會將連線恢復到剛建立完時的狀態。

查詢快取

上一步我們完成連線建立後，執行邏輯就來到了第二步：查詢快取。

與我們在應用端使用快取（如 HashMap/redis 等）類似，MySQL 拿到一個查詢請求後，會先去查詢快取看看，之前是不是執行過這條語句。之前執行過的語句及其結果會以 key-value 對的形式，直接快取在記憶體中。

key 是查詢的語句，value 是查詢的結果。

• 如果命中，就直接返回 value 結果。
• 如果未命中，繼續後面的流程，執行完後，將未命中的結果放入快取中。

你看，這個過程和我們平時在應用開發中實現的思路是不是非常類似？我們在學習 MySQL 同時也能學習到快取的實現方式。

儘管快取可以提高查詢效率，但是，大多數情況下建議不要使用查詢快取。

因為查詢快取往往弊 >> 利。簡言之，失效頻繁，對更新較多的情況下，快取命中率非常低。

查詢快取的失效非常頻繁，只要對一個表更新，則該表上所有的查詢快取都會被清空。因此很可能你費勁地把結果快取起來，還沒來得及使用呢，就被一個更新全清空了。

對於更新壓力大的資料庫來說，查詢快取命中率非常低。除非你的業務就是有張靜態表，很長時間才會更新一次。比如系統配置表，那才適合使用查詢快取。

適用的場景：靜態表或者變更頻率非常低的表。

這裡擴充套件一下，對於你確定要使用查詢快取的語句，可以用SQL_CACHE顯式指定，像下面這個語句一樣：

mysql> select SQL_CACHE * from T where id=10；

⚠️ MySQL 8.0 直接將查詢快取的整塊功能刪掉了，沒有這個功能。

分析器

接下來，就要對 SQL 進行解析了。

首先，先做「詞法分析」。

SQL語句是由多個字串和空格組成的，MySQL需要識別出裡面的字串分別是什麼，代表什麼。

例如，MySQL 從你輸入的"select"這個關鍵字識別出來，這是一個查詢語句。它也要把字串“T”識別成“表名T”，把字串“id”識別成“列id”。

然後做「語法分析」。

語法分析會根據語法規則，判斷 SQL 語句是否滿足 MySQL 語法。

如果你的語句不對，就會收到“You have an error in your SQL syntax”的錯誤提醒，例如這個語句select少打了開頭的字母“s”。

一般語法錯誤會提示第一個出現錯誤的位置，所以你要關注緊接“use near”的內容。

優化器

經過了分析器，接下來便是優化器的處理。

優化器在表裡有多個索引的時候，決定使用哪個索引；或者在一個語句多表關聯（join）的時候，決定各個表的連線順序。

舉個例子，

比如你執行下面這樣的語句，這個語句是執行兩個表的join：

mysql> select * from t1 join t2 using(ID) where t1.c=10 and t2.d=20;

• 既可以先從表t1裡面取出c=10的記錄的ID值，再根據ID值關聯到表t2，再判斷t2裡面d的值是否等於20。
• 也可以先從表t2裡面取出d=20的記錄的ID值，再根據ID值關聯到t1，再判斷t1裡面c的值是否等於10。

兩種執行方法的邏輯結果一樣的，但執行的效率會有不同，而優化器的作用就是決定選擇使用哪一個方案。

類似的，還有大表驅動小表等。你寫的 sql 語句的順序不一定是MySQL 真正執行的順序，原因就在這裡。

執行器

前面我們通過分析器知道要做什麼，通過優化器知道怎麼做，然後就進入了執行器，開始執行 SQL。

1.開始執行前，先做許可權驗證。

先判斷一下你對這個表T有沒有執行許可權，如果沒有，就會返回沒有許可權的錯誤(在實現上，如果命中查詢快取，會在查詢快取放回結果的時候，做許可權驗證。查詢也會在優化器之前呼叫 precheck 驗證許可權)。

2.如果有許可權，就開啟表繼續執行。執行器會根據表的引擎定義，選擇用這個引擎的介面。

比如這個例子中的表T中，ID欄位沒有索引，則執行器的執行流程是這樣的：

1. 呼叫 InnoDB 引擎介面取這個表的第一行，判斷ID值是不是 10，如果不是則跳過，如果是則將這行存在「結果集」中；
2. 呼叫引擎介面取“下一行”，重複相同的判斷邏輯，直到取到這個表的最後一行。
3. 執行器將遍歷過程中所有滿足條件的行組成的記錄集作為結果集返回給客戶端。

3.至此，語句執行完成。

如果表有索引，執行邏輯差不多。第一次呼叫的是“取滿足條件的第一行”這個介面，之後迴圈取“滿足條件的下一行”這個介面，這些介面都是引擎中已經定義好的。

這裡補充一下：我們在資料庫的慢查詢日誌中會看到一個 rows_examined 的欄位，表示某個語句執行過程中掃描了多少行。這個值就是在執行器每次呼叫引擎獲取資料行時累加的。

到這裡，我們的 SQL "奇幻漂流"也畫上一個句號。