高性能MySQL(1)——MYSQL架構

MySQL最重要、最與眾不同的特性是它的存儲引擎架構，這種架構將查詢處理與數據的存儲/提取相分離，使得可以在使用時根據不同的需求來選擇數據存儲的方式。

一、Mysql邏輯架構

如果能在頭腦中構建出一幅MySQL各組件之間如何協同工作的架構圖，就會有助于深入理解MySQL服務器。

mysql 數據庫的邏輯架構如下圖

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-Jx9utej6-1603348859176)(/Users/marron27/Documents/lizhengi/MySQL/高性能MySQL/T.Mysql邏輯圖.png)]

從上圖可以看出My SQL邏輯結構大致可以分為三層：

第一層結構主要處理客戶端與mysql服務端的連接、授權認證、安全等；

第二層是Mysql服務端的核心，功能包括查詢解析、分析、優化、緩存等，所有跨存儲引擎的功能都在這一層實現：存儲過程、觸發器、視圖等都在這一層實現；

第三層的存儲引擎主要負責數據存儲和提取，服務器通過API與存儲引擎進行通信，存儲引擎API包含幾十個底層函數，用于執行諸如“開始一個事務”或者“根據主鍵提取一行記錄”等操作。但存儲引擎不會去解析sql，不同存儲引擎之間不會通訊，只會簡單地響應上層服務器的請求

1.1、連接管理

每個客戶端連接成功，都會在服務器進程中擁有一個線程，服務器會緩存線程，該線程只能輪流在某個CPU中運行，所以不需要創建和銷毀線程。

1.2、安全性

當客戶端（應用）連接到MySQL服務器時,服務器需要對其進行認證。認證基于用戶名、原始主機信息和密碼等信息。

一旦客戶端連接成功，服務器會繼續驗證該客戶端是否具有執行某個特定查詢的權限

1.3、解析優化查詢

MySQL會解析査詢，并創建內部數據結構(解析樹)，然后對其進行各種優化，包括重寫查詢、決定表的讀取順序，以及選擇合適的索引等。

對于SELECT查詢語句，解析查詢之前會先查詢緩存，如果緩存能找到是不會去解析的，如果緩存查找不到，就會重現解析查詢，創建解析樹，然后對其進行查詢優化、決定表的讀取順序、選擇合適的索引等

二、并發控制

無論何時，只要有多個査詢需要在同一時刻修改數據，都會產生并發控制的問題。

并發即指在同一時刻，多個操作并行執行。MySQL對并發的處理主要應用了兩種機制——是"鎖"和"多版本控制"。

2.1、鎖機制

在處理并發讀或者寫時，可以通過實現一個由兩種類型的鎖組成的鎖系統來解決問題：

共享鎖：也稱為讀鎖，讀鎖允許多個連接可以同一時刻并發的讀取同一資源,互不干擾；
排他鎖：也稱為寫鎖，一個寫鎖會阻塞其他的寫鎖或讀鎖，保證同一時刻只有一個連接可以寫入數據，同時防止其他用戶對這個數據的讀寫。

2.2、鎖粒度

所謂的鎖策略，就是在鎖的開銷和數據的安全性之間尋求平衡，這種平衡當然也會影響到性能。

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

表級鎖（服務器層）：MySQL獨立于存儲引擎提供表鎖，例如，對于ALTER TABLE語句，服務器提供表鎖(table-level lock)。表鎖是最基本也是開銷最小的策略；
行級鎖（引擎層）：InnoDB和Falcon存儲引擎提供行級鎖，此外，BDB支持頁級鎖。行級鎖可以最大程度地支持并發處理（同時也帶來了最大的鎖開銷）。

另外，值得一提的是，MySQL的一些存儲引擎（如InnoDB、BDB）除了使用封鎖機制外，還同時結合MVCC機制，即多版本并發控制(Multi-Version Concurrent Control)，來實現事務的并發控制，從而使得只讀事務不用等待鎖，提高了事務的并發性。

2.3、多版本并發控制

MVCC的實現：通過保存數據資源在不同時間點的快照實現的。根據事務開始的時間不同，每個事務看到的數據快照版本是不一樣的。

InnoDB中的MVCC實現：通過在每行記錄后面保存兩個隱藏的列來實現，一個保存了行的創建時間，一個保存了行的過期時間。

SELECT

當讀取記錄時，存儲引擎會選取滿足下面兩個條件的行作為讀取結果。

讀取記錄行的開始版本號必須早于當前事務的版本號。也就是說，在當前事務開始之前，這條記錄已經存在。在事務開始之后才插入的行，事務不會看到。

讀取記錄行的過期版本號必須晚于當前事務的版本號。也就是說，當前事務開始的時候，這條記錄還沒有過期。在事務開始之前就已經過期的數據行，該事務也不會看到。
INSERT

存儲引擎為新插入的每一行保存當前的系統版本號作為這一行的開始版本號。
UPDATE

存儲引擎會新插入一行記錄，當前的系統版本號就是新記錄行的開始版本號。同時會將原來行的過期版本號設為當前的系統版本號。
DELETE

存儲引擎將刪除的記錄行的過期版本號設置為當前的系統版本號。

MVCC只在 REPEATABLE READ 和 READ COMMITTED 兩個隔離級別下工作。

三、事務

3.1、事務的ACID特性

數據庫的事務處理的原則是保證ACID的正確性。

事務是由一組SQL語句組成的邏輯處理單元，事務具有以下4個屬性：

原子性（Atomicity）：事務是一個原子操作單元，其對數據的修改，要么全都執行，要么全都不執行，不可能只執行其中的一部分。（不可分割）
一致性（Consistent）：在事務開始和完成時，數據都必須保持一致狀態。這意味著所有相關的數據規則都必須應用于事務的修改，以保持數據的完整性；事務結束時，所有的內部數據結構(如B樹索引或雙向鏈表)也都必須是正確的。（狀態更改一致性）
隔離性（Isolation）：數據庫系統提供一定的隔離機制，保證事務在不受外部并發操作影響的“獨立”環境執行。這意味著事務處理過程中的中間狀態對外部是不可見的。（執行過程隔離不可見）
持久性（Durable）：事務完成之后，它對于數據的修改是永久性的，即使出現系統故障也能夠保持。（持久生效）

3.2、事務處理帶來的問題

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

更新丟失（Lost Update）：當兩個或多個事務選擇同一行，然后基于最初選定的值更新該行時，由于每個事務都不知道其他事務的存在，就會發生丟失更新問題－－最后的更新覆蓋了由其他事務所做的更新。
臟讀（Dirty Reads）：一個事務正在對一條記錄做修改，在這個事務完成并提交前，這條記錄的數據就處于不一致狀態；這時，另一個事務也來讀取同一條記錄，如果不加控制，第二個事務讀取了這些"臟"數據，并據此做進一步的處理，就會產生未提交的數據依賴關系。這種現象被形象地叫做"臟讀"。
不可重復讀（Non-Repeatable Reads）：一個事務在讀取某些數據后的某個時間，再次讀取以前讀過的數據，卻發現其讀出的數據已經發生了改變、或某些記錄已經被刪除了！這種現象就叫做"不可重復讀"。
幻讀（Phantom Reads）：一個事務按相同的查詢條件重新讀取以前檢索過的數據，卻發現其他事務插入了滿足其查詢條件的新數據，這種現象就稱為"幻讀"。

3.3、Mysql隔離級別

READ UNCOMMITTED ：事務可以看到其他事務沒有被提交的數據（臟數據）。
READ COMMITTED ：事務可以看到其他事務已經提交的數據。
REPEATABLE READ ：保證事務中多次查詢的結果相同（Innodb默認級別），會出現幻讀。
SERIALIZABLE ：所有事務順序執行，對所有read操作加鎖。保證一致性。