《高效能MySQL》筆記-整體架構

MySQL邏輯架構

第一層

大多數基於網路的客戶端/伺服器的工具或者服務都有類似的架構。比如連線處理、授權認證、安全等等。

第二層

大多數MySQL的核心服務功能都在這一層，包括查詢解析、分析、優化、快取以及所有的內建函式（例如，日期、時間、數學和加密函式），所有跨儲存引擎的功能都在這一層實現：儲存過程、觸發器、檢視等。

第三層

包含了儲存引擎。儲存引擎負責MySQL中資料的儲存和提取。和GNU/Linux下的各種檔案系統一樣，每個儲存引擎都有它的優勢和劣勢。伺服器通過API與儲存引擎進行通訊。這些介面遮蔽了不同儲存引擎之間的差異，使得這些差異對上層的查詢過程透明。儲存引擎API包含一些底層函式，用於執行諸如“開始一個事務”或者“根據主鍵提取一行記錄”等操作。但儲存引擎不會去解析SQL，不同儲存引擎之間也不會相互通訊，而只是簡單地響應上層伺服器的請求。

連線管理

每個客戶端連線都會在伺服器程式中擁有一個執行緒，這個連線的查詢只會在這個單獨的執行緒中執行，該執行緒只能輪流在某個CPU核心或者CPU中執行。伺服器會負責快取執行緒，因此不需要為每一個新建的連線建立或者銷燬執行緒（執行緒池Thread-Pooling）。

優化與執行

MySQL會解析查詢，並建立內部資料結構（解析樹），然後對其進行各種優化，包括重寫查詢、決定表的讀取順序，以及選擇合適的索引等。使用者可以通過特殊的關鍵字提示（hint）優化器，影響它的決策過程。也可以請求優化器解釋（explain）優化過程的各個因素，使使用者可以知道伺服器是如何進行優化決策的，並提供一個參考基準，便於使用者重構查詢和schema、修改相關配置，使應用盡可能高效執行。
優化器並不關心表使用的是什麼儲存引擎，但儲存引擎對於優化查詢是有影響的。優化器會請求儲存引擎提供容量或某個具體操作的開銷資訊，以及表資料的統計資訊等。例如，某些儲存引擎的某種索引，可能對一些特定的查詢有優化。
對於SELECT語句，在解析查詢之前，伺服器會先檢查查詢快取（Query Cache），如果能夠在其中找到對應的查詢，伺服器就不必再執行查詢解析、優化和執行的整個過程，而是直接返回查詢快取中的結果集。

總結

MySQL擁有分層的架構。上層的伺服器層是服務和查詢執行引擎，下層則是儲存引擎。雖然有很多不同作用的外掛API，但儲存引擎API還是最重要的。如果能理解MySQL在儲存引擎和服務層之間處理查詢時如何通過API來回互動，就能抓住MySQL的核心基礎架構的精髓。
MySQL最初基於ISAM構建（後來被MyISAM取代），其後陸續新增了更多的儲存引擎和事務支援。MySQL有一些怪異的行為是由於歷史遺留導致的。例如，在執行ALTER TABLE時，MySQL提交事務的方式是由於儲存引擎的架構直接導致的，並且資料字典也儲存在.frm檔案中（這並不是說InnoDB會導致ALTER變成非事務型的。對於InnoDB來說，所有的操作都是事務）。
當然，儲存引擎API的架構也有一些缺點。有時候選擇多並非好事，而在MySQL5.0和MySQL5.1中有太多的儲存引擎可以選擇。 InnoDB對於95%以上的使用者來說都是最佳的選擇，所以其他的儲存引擎可能只是讓事情變更復雜難搞，當然也不可否認某些情況下某些儲存引擎能更好的滿足需求。
Oracle一開始收購了InnoDB，之後又收購了MySQL，在同一個屋簷下對於兩者都是有利的。InnoDB和MySQL伺服器之間可以更快的協同發展。MySQL依然基於GPL協議開放全部原始碼，社群和客戶都可以獲得堅固而穩定的資料庫，MySQL正在變得越來越可擴充套件和有用。