Mysql是主流的開(kāi)源關(guān)系型數(shù)據(jù)庫(kù)，提供高性能的數(shù)據(jù)存儲(chǔ)服務(wù)。在做后端開(kāi)發(fā)時(shí)，有時(shí)會(huì)遇到性能瓶頸，這些瓶頸有時(shí)并不是來(lái)自應(yīng)用本身，而是來(lái)自數(shù)據(jù)庫(kù)層面。

所以所以掌握Mysql的一些底層原理有助于我們更好地理解Mysql，對(duì)Mysql進(jìn)行性能調(diào)優(yōu)，

從而開(kāi)發(fā)高性能的后端服務(wù)。

1、mysql的邏輯框架

mysql邏輯框架圖如下：

最上層是處理客戶(hù)端過(guò)來(lái)的連接的。

主要做連接處理、授權(quán)認(rèn)證、安全等。Mysql在這一層維護(hù)了一個(gè)線(xiàn)程池，用于處理來(lái)自客戶(hù)端的連接。Mysql可以使用用戶(hù)名密碼認(rèn)證，

也可以使用SSL基于X.509證書(shū)認(rèn)證。

第二層由三部分組成：查詢(xún)緩存、解析器、優(yōu)化器。解析器用來(lái)解析SQL語(yǔ)句，優(yōu)化器會(huì)對(duì)解析之后的語(yǔ)句進(jìn)行優(yōu)化。

在解析查詢(xún)前，服務(wù)器會(huì)先檢查查詢(xún)緩存，如果能在其中找到對(duì)應(yīng)的查詢(xún)結(jié)果，則無(wú)需再進(jìn)行查詢(xún)解析、優(yōu)化等過(guò)程，直接返回查詢(xún)結(jié)果。存儲(chǔ)過(guò)程、觸發(fā)器、視圖等都在這一層實(shí)現(xiàn)。

第三層是存儲(chǔ)引擎，存儲(chǔ)引擎負(fù)責(zé)在MySQL中存儲(chǔ)數(shù)據(jù)、提取數(shù)據(jù)、開(kāi)啟一個(gè)事務(wù)等等。存儲(chǔ)引擎通過(guò)API與上層進(jìn)行通信，這些API屏蔽了不同存儲(chǔ)引擎之間的差異，使得這些差異對(duì)上層查詢(xún)過(guò)程透明。存儲(chǔ)引擎不會(huì)去解析SQL。mysql最常用的存儲(chǔ)引擎是InnoDB。

2、mysql的并發(fā)控制

如果多個(gè)線(xiàn)程同時(shí)操作數(shù)據(jù)，就有可能引發(fā)并發(fā)控制的問(wèn)題。

2-1、讀寫(xiě)鎖

如果多個(gè)線(xiàn)程都只是讀數(shù)據(jù)，其實(shí)可以一起讀，不會(huì)互相影響，這個(gè)時(shí)候應(yīng)該使用“讀鎖”，也稱(chēng)為共享鎖。

獲取讀鎖的線(xiàn)程之間互相不會(huì)阻塞，可以同時(shí)讀取一個(gè)資源。

如果有一個(gè)線(xiàn)程需要寫(xiě)數(shù)據(jù)，則應(yīng)該使用“寫(xiě)鎖”，也成為排它鎖。

寫(xiě)鎖會(huì)阻塞其它的寫(xiě)鎖和讀鎖，直至寫(xiě)操作完成。

2-2、鎖粒度

首先明確一個(gè)概念：在給定的資源上，需要加鎖的數(shù)據(jù)越少，系統(tǒng)能夠承載的并發(fā)量就越高。

但加鎖也是需要消耗資源的，如果系統(tǒng)花費(fèi)大量的時(shí)間來(lái)管理鎖，而不是存取數(shù)據(jù)，

那么系統(tǒng)的性能可能會(huì)因此受影響。

所以一個(gè)好的“鎖策略”就是要在鎖的開(kāi)銷(xiāo)和數(shù)據(jù)的安全性之間尋求平衡，Mysql支持多個(gè)存儲(chǔ)引擎的架構(gòu)，

每種存儲(chǔ)引擎都可以實(shí)現(xiàn)自己的鎖策略和鎖粒度。

2-3、表鎖和行鎖

表鎖顧名思義就是鎖住整張表。表鎖開(kāi)銷(xiāo)比較小。對(duì)表加寫(xiě)鎖后，其它用戶(hù)對(duì)這張表的所有讀寫(xiě)操作都會(huì)被阻塞。

在Mysql中，盡管存儲(chǔ)引擎可以提供自己的鎖，但Mysql有時(shí)候也會(huì)使用表鎖，比如ALTER TABLE之類(lèi)的語(yǔ)句。

寫(xiě)鎖比讀鎖有更高的優(yōu)先級(jí)，因此一個(gè)寫(xiě)鎖請(qǐng)求可能會(huì)插入到讀鎖隊(duì)列的前面。

行級(jí)鎖即鎖住整行，可以最大程度地支持并發(fā)處理，但加解鎖的開(kāi)銷(xiāo)也會(huì)比較大。行級(jí)鎖只在儲(chǔ)存引擎層實(shí)現(xiàn)，

所有的存儲(chǔ)引擎都以自己的方式實(shí)現(xiàn)了行級(jí)鎖。

3、MVCC

MVCC即“多版本并發(fā)控制”，可以認(rèn)為MVCC是行級(jí)鎖的一個(gè)變種，但是它在很多情況下避免了加鎖操作，

因此開(kāi)銷(xiāo)更低。

主流的關(guān)系型數(shù)據(jù)庫(kù)都實(shí)現(xiàn)了MVCC，但實(shí)現(xiàn)機(jī)制各有不同。實(shí)際上MVCC也沒(méi)有一個(gè)統(tǒng)一的標(biāo)準(zhǔn)。

但大都實(shí)現(xiàn)了非阻塞的讀操作，寫(xiě)操作也只是鎖定必要的行。

MVCC保證的是每個(gè)事務(wù)里面在執(zhí)行期間看到的數(shù)據(jù)都是一致的。

但不同的事務(wù)由于開(kāi)始的時(shí)間不同，所以可能對(duì)同一張表，同一時(shí)刻看到的數(shù)據(jù)是不一樣的。

在Mysql的InnoDB引擎，是通過(guò)給每行記錄后面保存兩個(gè)隱藏的列來(lái)實(shí)現(xiàn)的。

一個(gè)是保存行的創(chuàng)建時(shí)間，另一個(gè)保存了行的過(guò)期時(shí)間（或刪除時(shí)間）。

實(shí)際上存儲(chǔ)的并不是實(shí)際的一個(gè)時(shí)間戳，而是‘系統(tǒng)版本號(hào)'。

每次開(kāi)啟一個(gè)事務(wù)，系統(tǒng)版本號(hào)都會(huì)遞增。事務(wù)開(kāi)始時(shí)，系統(tǒng)版本號(hào)會(huì)作為事務(wù)的版本號(hào)，用來(lái)和查詢(xún)到的行的版本號(hào)進(jìn)行比較。

下面分別介紹常見(jiàn)的CRUD操作中版本號(hào)是怎么工作的：

INSERT

保存當(dāng)前系統(tǒng)版本好的作為行版本號(hào)

DELETE

保存當(dāng)前的系統(tǒng)版本號(hào)到這行數(shù)據(jù)的“刪除版本”。

UPDATE

插入一行新紀(jì)錄，保存當(dāng)前系統(tǒng)版本號(hào)作為航版本號(hào)，同時(shí)保存當(dāng)前系統(tǒng)版本號(hào)到原來(lái)的行的“刪除版本”。

SELECT

只查找版本早于當(dāng)前事務(wù)版本的行。這樣可以保證事務(wù)讀取的行，要么之前就存在，

要么是這個(gè)事務(wù)本身自己插入或者修改的。

行的“刪除版本”要么未定義，要么大于當(dāng)前事務(wù)版本號(hào)。這樣可以確保事務(wù)讀取到的行，

在事務(wù)之前沒(méi)有被刪除。

MVCC只在REPEATABLE READ和READ COMMITTED兩個(gè)隔離級(jí)別下工作，其它兩個(gè)隔離級(jí)別不能工作。

因?yàn)镽EAD UNCOMMITTED總是讀取最新的數(shù)據(jù)防，而不是符合當(dāng)前事務(wù)版本的數(shù)據(jù)行。而SERIALIZABLE則會(huì)對(duì)所有讀取的行都加鎖。

以上就是mysql的并發(fā)控制原理的詳細(xì)內(nèi)容，如果大家有任何補(bǔ)充可以聯(lián)系腳本之家小編。