系統隻要能從資料庫連接配接池擷取到一個資料庫連接配接，就能執行CRUD。可通過資料庫連接配接将待執行SQL發給MySQL。
大部分 crud boy隻知道：
- 執行insert語句後，在表裡會多條資料
- 執行update後，會更改表資料
- 執行delete後，會删除表裡資料
- 執行select後，會查詢表裡資料出來
- 要是SQL性能丢人，建幾個索引解決
- …
這應該是目前行業内很多工程師對資料庫的一個認知，完全當他是個黑盒來建表及執行SQL。
網絡連接配接必須有線程處理
假設資料庫伺服器的連接配接池中的某個連接配接，接收到一條SQL網絡請求，請思考：
- 誰負責從這個連接配接中去監聽網絡請求？
- 誰負責從網絡連接配接裡把請求資料讀取出來？
網絡連接配接得有一個線程來監聽請求及讀取請求資料，比如從網絡連接配接中讀取和解析出來一條業務系統發的SQL語句：
SQL接口
負責處理接收到的SQL語句。
MySQL的工作線程從一個網絡連接配接中讀出一個SQL語句後，會如何執行該SQL呢？
MySQL提供了SQL接口（SQL Interface），一套執行SQL語句的接口，專門執行業務系統發送的那些CRUD語句
是以MySQL的工作線程接收到SQL語句之後，就會轉交給SQL接口去執行：
查詢解析器
那SQL接口怎麼執行SQL語句的？這玩意能懂這些SQL語句？
假設有如下SQL：
select id,name,age from users where id=1
這就需要查詢解析器（Parser），負責解析SQL語句，比如對那個SQL拆解成：
- 要從“users”表裡查詢資料
- 查詢“id”字段的值等于1的那行資料
- 對查出來的那行資料要提取裡面的“id,name,age”三字段
SQL解析也就是按SQL文法來解析SQL語句意欲何為：
查詢優化器
通過解析器知道SQL要幹啥了，然後就得找查詢優化器（Optimizer）選擇一個最優查詢路徑。
啥叫最優查詢路徑呢？
之前的那個SQL：從“users”表裡查詢資料，查“id”字段的值等于1的那行資料，對查出來的那行資料要提取裡面的“id,name,age”三個字段。
要完成此事有如下查詢路徑：
- 直接定位到users表中的id字段等于1的那行資料，查出來那行資料的id、name、age三個字段值
- 先把users表中的每行資料的“id,name,age”三個字段的值都查出來，然後從這批資料裡過濾出來“id”字段等于1的那行資料的“id,name,age”三個字段
可見，完成該SQL，兩條路徑都能實作，那到底選哪個呢？顯然第一種性能更好。
是以查詢優化器大概就是這個意義，他會針對你的SQL生成查詢路徑樹，選擇最優查詢路徑。
調用存儲引擎接口，真正執行SQL語句。
把查詢優化器選擇的最優查詢路徑，即到底應該按照一個什麼樣的順序和步驟去執行這個SQL語句的計劃，把該計劃交給底層的存儲引擎去真正執行。
假設我們的資料有的存在記憶體，有的存在磁盤檔案，那到底怎麼知道
- 哪些資料在記憶體？
- 哪些在磁盤？
執行時：
- 是更新記憶體資料？
- 還是更新磁盤資料？
若更新磁盤資料：
- 先查詢哪個磁盤檔案
- 再更新哪個磁盤檔案？
這就需要存儲引擎，就是個執行SQL語句的，會按步驟查詢記憶體緩存資料，更新磁盤數 據，查詢磁盤資料等，執行此類的一系列的操作：
MySQL架構設計中，SQL接口、SQL解析器、查詢優化器都是通用的，屬于一套元件。但支援各種存儲引擎，如InnoDB、MyISAM、Memory等，可以選擇具體使用哪種存儲引擎來負責執行SQL。
執行器
根據執行計劃調用存儲引擎的接口。
存儲引擎可幫助我們去通路記憶體及磁盤上的資料，那誰來調存儲引擎的接口？
那就是執行器，會根據優化器選擇的執行方案，按照一定的順序和步驟調用存儲引擎的接口，執行SQL邏輯。