在使用Impala這種所謂大數據引擎的時候，總會感覺有些地方設計的不是那么盡善盡美，比如說緩存，Impala的查詢結果是沒有經過緩存的，也就是說每次都相當于需要重新對文件執行一遍查詢。

MySQL基本架構如下圖，是MySQL的邏輯架構圖：

最上層的服務并不是MySQL所獨有的，大多數基于網絡的客戶端/服務器的工具或者服務都有類似的架構，比如連接處理、授權認證、安全等等。

第二層架構是MySQL比較有意思的部分大多數MySQL的核心服務功能都在這一層。包括查詢解析、分析、優化、緩存以及所有的內置函數，所有跨存儲引擎的功能都在這一層實現：存儲過程、觸發器、視圖等。

第三層包含了存儲引擎。存儲引擎負責MySQL中數據的存儲和提取。和GNU/Linux下的各種文件系統一樣，每個存儲引擎都有它的優勢和劣勢。服務器通過API與存儲引擎進行通信。這些接口屏蔽了不同存儲引擎之間的差異。

下面挑幾個模塊解釋一下：

1.解析器

SQL命令傳遞到解析器的時候會被解析器驗證和解析。解析器是由Lex和YACC實現的，是一個很長的腳本。

主要功能：

將SQL語句分解成數據結構，并將這個結構傳遞到后續步驟，以后SQL語句的傳遞和處理就是基于這個結構的

如果在分解構成中遇到錯誤，那么就說明這個sql語句是不合理的

2.優化器

SQL語句在查詢之前會使用查詢優化器對查詢進行優化。他使用的是“選取-投影-聯接”策略進行查詢。

用一個例子就可以理解：select uid,name from user where gender = 1;

這個select 查詢先根據where 語句進行選取，而不是先將表全部查詢出來以后再進行gender過濾

這個select查詢先根據uid和name進行屬性投影，而不是將屬性全部取出以后再進行過濾

將這兩個查詢條件聯接起來生成最終查詢結果。

3.緩存

如果查詢緩存有命中的查詢結果，查詢語句就可以直接去查詢緩存中取數據。

這個緩存機制是由一系列小緩存組成的。比如表緩存，記錄緩存，key緩存，權限緩存等。

補充知識

1.查詢優化和執行(Optimization and Execution)

MySQL將用戶的查詢語句進行解析，并創建一個內部的數據結構——分析樹，然后進行各種優化，例如重寫查詢、選擇讀取表的順序，以及使用哪個索引等。

查詢優化器不關心一個表所使用的存儲引擎，但是存儲引擎會影響服務器如何優化查詢。優化器通過存儲引擎獲取一些參數、某個操作的執行代價、以及統計信息等。在解析查詢之前，服務器會先訪問查詢緩存(query cache)——它存儲SELECT語句以及相應的查詢結果集。如果某個查詢結果已經位于緩存中，服務器就不會再對查詢進行解析、優化、以及執行。它僅僅將緩存中的結果返回給用戶即可，這將大大提高系統的性能。

2.并發控制(鎖粒度)

MySQL提供兩個級別的并發控制：服務器級(the server level)和存儲引擎級(the storage engine level)。加鎖是實現并發控制的基本方法，MySQL中鎖的粒度：

表級鎖：MySQL獨立于存儲引擎提供表鎖，例如，對于ALTER TABLE語句，服務器提供表鎖(table-level lock)。

行級鎖：InnoDB和Falcon存儲引擎提供行級鎖，此外，BDB支持頁級鎖。InnoDB的并發控制機制，下節詳細討論。

另外，值得一提的是，MySQL的一些存儲引擎(如InnoDB、BDB)除了使用封鎖機制外，還同時結合MVCC機制，即多版本兩階段封鎖協議(Multiversion two-phrase locking protocal)，來實現事務的并發控制，從而使得只讀事務不用等待鎖，提高了事務的并發性。

注意： 行級鎖只在存儲引擎層實現，而MySQL服務器層沒有實現。服務器層完全不了解存儲引種的鎖實現。

3.事務

MySQL中，InnoDB和BDB都支持事務處理。這里主要討論InnoDB的事務處理。

事務的ACID特性：

事務是由一組SQL語句組成的邏輯處理單元，事務具有以下4個屬性，通常簡稱為事務的ACID屬性。

原子性(Atomicity)：事務是一個原子操作單元，其對數據的修改，要么全都執行，要么全都不執行。

一致性(Consistent)：在事務開始和完成時，數據都必須保持一致狀態。這意味著所有相關的數據規則都必須應用于事務的修改，以保持數據的完整性;事務結束時，所有的內部數據結構(如B樹索引或雙向鏈表)也都必須是正確的。

隔離性(Isolation)：數據庫系統提供一定的隔離機制，保證事務在不受外部并發操作影響的“獨立”環境執行。這意味著事務處理過程中的中間狀態對外部是不可見的，反之亦然。

持久性(Durable)：事務完成之后，它對于數據的修改是永久性的，即使出現系統故障也能夠保持。

事務處理帶來的相關問題：

由于事務的并發執行，帶來以下一些著名的問題：

更新丟失(Lost Update)：當兩個或多個事務選擇同一行，然后基于最初選定的值更新該行時，由于每個事務都不知道其他事務的存在，就會發生丟失更新問題--最后的更新覆蓋了由其他事務所做的更新。

臟讀(Dirty Reads)：一個事務正在對一條記錄做修改，在這個事務完成并提交前，這條記錄的數據就處于不一致狀態;這時，另一個事務也來讀取同一條記錄，如果不加控制，第二個事務讀取了這些“臟”數據，并據此做進一步的處理，就會產生未提交的數據依賴關系。這種現象被形象地叫做”臟讀”。

不可重復讀(Non-Repeatable Reads)：一個事務在讀取某些數據后的某個時間，再次讀取以前讀過的數據，卻發現其讀出的數據已經發生了改變、或某些記錄已經被刪除了!這種現象就叫做“不可重復讀”。

幻讀(Phantom Reads)：一個事務按相同的查詢條件重新讀取以前檢索過的數據，卻發現其他事務插入了滿足其查詢條件的新數據，這種現象就稱為“幻讀”。