內容源于《高性能MySQL》

一、MySQL邏輯架構

架構圖：

最上層不是Mysql獨有的， 比如連接處理，授權認證， 安全 等等 第二層核心服務功能，包括查詢解析，分析，優化，緩存以及所有內置函數，存儲過程，觸發器，視圖等都在這層實現 第三層 存儲引擎，存儲引擎API包含幾十個底層函數

二、優化與執行 什么是優化： MySQL解析查詢，并創建內部數據結構（解析樹），然后對其進行各種優化，包括重寫查詢，決定表的讀取順序，以及選擇合適的索引等。 （用戶可以通過特殊的關鍵字提示優化器，影響它的決策過程。也可以請求優化器解釋優化過程的各個因素）

三、并發控制 采用讀寫鎖來進行并發控制，提高并發性的方式就是讓鎖定的對象更有選擇性，只鎖定部分數據，而不是所有的資源，這就是鎖粒度要考慮的問題。

表鎖：MySQL最基本的鎖策略，開銷最小的策略。它會鎖定整張表，用戶對表進行寫操作前，先獲得寫鎖，這會阻塞其他用戶對該表的所有讀寫操作。只有沒有寫鎖時，其他讀取用戶才能獲得讀鎖，讀鎖之間是不相互阻塞的。

行級鎖：行級鎖可以最大程度地支持并發處理（最大鎖開銷），InnoDB和XtraDB，還有其他一些存儲引擎中實現了行級鎖，行級鎖只在存儲引擎層實現，而MySQL服務器層沒有實現。

四、事務 事務這個概念比較基礎，就不過多介紹。 記住一句話要么都做，要么都不做的。 還有ACID四大特征：原子性，一致性（從一個一致性的狀態轉換到另一個一致性的狀態），隔離性，持久性。

五、隔離級別 四種隔離級別 1. READ UNCOMMITED(未提交讀) 其他事物可以讀取未提交數據，會導致臟讀（讀臟數據），這種會導致很多問題，一般不采用。 2. READ COMMITED(提交讀) 事務提交之前，所做的任何修改對其他事務不可見，也叫不可重復讀，同一個事務執行兩次相同的查詢，可能得到不一樣的結果。 3. REPEATABLE READ(可重復讀) 保證了在同一個事務中多次讀取同樣記錄的結果是一致的。但無法解決幻讀問題。即當某個事務在讀取范圍內的記錄時，另外一個事務又在該范圍內插入了新紀錄，導致之前的事務再次讀取時，產生幻行。 4. SERIALIZABLE（可串行化） 最高的隔離級別，通過加鎖確保數據的一致性。

六、死鎖 1. 多個事務不同順序鎖定資源時，會產生死鎖， 2. 多個事務同時鎖定同一個資源，產生死鎖。 InnoDB目前處理死鎖的方法是，將持有最小行級排他鎖的事務進行回滾（相對比較簡單的死鎖回滾方法） 越復雜的系統，越能檢測到死鎖的循環依賴，并立即返回一個錯誤，否則會導致出現非常慢的查詢。

七、MySQL中的事務 MySQL 提供了兩種事務型的存儲引擎：InnoDB 和 NDB Cluster MySQL默認采用自動提交模式，即每個查詢都被當做一個事務執行提交操作。另外有一些命令在執行之前會強制執行commit提交，比如ALTER TABLE。

MySQL服務層不管理事務，事務是由下層的存儲引擎實現的，所以同一個事務中，使用多種存儲引擎是不可靠的。

InnoDB采用的是兩階段鎖定協議，事務執行過程中，隨時可以鎖定，鎖只有在執行commit或者rollback的時候才會釋放，并且同一個時刻被釋放。

八、多版本并發控制MVCC MySQL的大多數事務型存儲引擎都不是簡單的行級鎖。各大數據庫基本都采用MVCC，但不盡相同。

InnoDB的簡化版：（MVCC實現原理） 在每行記錄后面保存兩個隱藏的列來實現，一個保存了行的創建版本號，一個保存行的過期版本號（刪除版本號）。

版本號： 1. 系統版本號：每開始一個新的事務，系統版本號就會自動增加 2. 事務版本號：事務開始時刻的系統版本號

當執行select操作時候： 1. 只查找版本早于當前事務版本的數據行。 確保事務讀取的行，在事務開始之前就存在的，或者是事務自身插入或者修改過的。 2. 行的刪除版本號要么未定義，要么大于當前事務版本號。 確保事務查詢到的行，在事務開始之前沒被刪除。

insert操作： 為新插入的每一行保存當前系統版本號為行創建版本號。

delete操作： 為刪除的行保存當前系統版本號作為行刪除版本號。

update操作： 為插入一行新數據保存當前版本號作為該新行行創建版本號，同時保存當前系統版本號到原來的行作為行刪除版本號。

可見update = delete+insert

采用MVCC這個原理，大多操作可以不用加鎖，使得讀數據操作簡單，性能好，缺點是額外的存儲空間消耗，更多的行檢查和維護工作。MVCC只能在REPEATABLE READ 和READ COMMITTED兩個隔離級別下工作。其他兩個隔離級別跟MVCC不兼容。