按鎖思想分類

悲觀鎖

優(yōu)點(diǎn)：適合在寫多讀少的并發(fā)環(huán)境中使用，雖然無法維持非常高的性能，但是在樂觀鎖無法提更好的性能前提下，可以做到數(shù)據(jù)的安全性

缺點(diǎn)：加鎖會(huì)增加系統(tǒng)開銷，雖然能保證數(shù)據(jù)的安全，但數(shù)據(jù)處理吞吐量低，不適合在讀書寫少的場(chǎng)合下使用

樂觀鎖

優(yōu)點(diǎn)：在讀多寫少的并發(fā)場(chǎng)景下，可以避免數(shù)據(jù)庫(kù)加鎖的開銷，提高DAO層的響應(yīng)性能，很多情況下ORM工具都有帶有樂觀鎖的實(shí)現(xiàn)，所以這些方法不一定需要我們?nèi)藶榈娜?shí)現(xiàn)。

缺點(diǎn)：在寫多讀少的并發(fā)場(chǎng)景下，即在寫操作競(jìng)爭(zhēng)激烈的情況下，會(huì)導(dǎo)致CAS多次重試，沖突頻率過高，導(dǎo)致開銷比悲觀鎖更高。

實(shí)現(xiàn)：數(shù)據(jù)庫(kù)層面的樂觀鎖其實(shí)跟CAS思想類似， 通數(shù)據(jù)版本號(hào)或者時(shí)間戳也可以實(shí)現(xiàn)。

按鎖粒度分類

表鎖

表鎖是指對(duì)一整張表加鎖，一般是 DDL 處理時(shí)使用

表鎖由 MySQL Server 實(shí)現(xiàn)，表級(jí)鎖更適合于以查詢?yōu)橹?#xff0c;并發(fā)用戶少，只有少量按索引條件更新數(shù)據(jù)的應(yīng)用，如Web 應(yīng)用

優(yōu)點(diǎn)：開銷小，加鎖快；不會(huì)出現(xiàn)死鎖；

缺點(diǎn)：鎖定粒度大，發(fā)生鎖沖突的概率最高，并發(fā)度最低。

頁鎖：介于表鎖和行鎖之間。BDB 存儲(chǔ)引擎采用的是頁面鎖(page-level locking)

行鎖

行鎖則是鎖定某一行或者某幾行，或者行與行之間的間隙。

行鎖則是存儲(chǔ)引擎實(shí)現(xiàn)，行級(jí)鎖更適合于有大量按索引條件并發(fā)更新少量不同數(shù)據(jù)，同時(shí)又有并發(fā)查詢的應(yīng)用，如一些在線事務(wù)處理(OLTP)系統(tǒng)

優(yōu)點(diǎn)：鎖定粒度最小，發(fā)生鎖沖突的概率最低，并發(fā)度也最高。

缺點(diǎn)：開銷大，加鎖慢；會(huì)出現(xiàn)死鎖；

InnoDB行鎖類型

標(biāo)準(zhǔn)

共享鎖(S)：允許一個(gè)事務(wù)去讀一行，阻止其他事務(wù)獲得相同數(shù)據(jù)集的排他鎖

排他鎖(X)：允許獲得排他鎖的事務(wù)更新數(shù)據(jù)，阻止其他事務(wù)取得相同數(shù)據(jù)集的共享讀鎖和排他寫鎖。

數(shù)據(jù)庫(kù)并發(fā)場(chǎng)景主要有三種：

讀-讀：不存在任何問題，也不需要并發(fā)控制

讀-寫：有隔離性問題，可能遇到臟讀，幻讀，不可重復(fù)讀

寫-寫：可能存更新丟失問題，比如第一類更新丟失，第二類更新丟失

更細(xì)粒度

共享鎖(S)

排他鎖(X)

意向共享鎖(IS)：事務(wù)打算給數(shù)據(jù)行加行共享鎖，事務(wù)在給一個(gè)數(shù)據(jù)行加共享鎖前必須先取得該表的 IS 鎖。

意向排他鎖(IX)：事務(wù)打算給數(shù)據(jù)行加行排他鎖，事務(wù)在給一個(gè)數(shù)據(jù)行加排他鎖前必須先取得該表的 IX 鎖。

一致性(非)鎖定讀

一致性非鎖定讀：

一致性非鎖定讀由MVCC(多版本并發(fā)控制)實(shí)現(xiàn)。MVCC其實(shí)就是在每一行記錄后面增加兩個(gè)隱藏列，記錄創(chuàng)建版本號(hào)和刪除版本號(hào)，而每一個(gè)事務(wù)在啟動(dòng)的時(shí)候，都有一個(gè)唯一的遞增的版本號(hào)

詳細(xì)可參考前文《深入理解MySQL系列之redo log、undo log和binlog》

一致性鎖定讀：

SELECT ... FOR UPDATE //加X鎖

SELECT ... LOCK IN SHARE MODE //加S鎖

鎖的算法

行鎖的三種算法：

Record Lock：當(dāng)個(gè)行記錄上的鎖

Gap Lock：間隙鎖，鎖定一個(gè)范圍，但不包含記錄本身

Next Key Lock：Gap Lock + Record Lock ，鎖定一個(gè)范圍，并且鎖定記錄本身(只有REPEATABLE READ隔離級(jí)別有)

在默認(rèn)事務(wù)隔離級(jí)別(REPEATABLE READ)下，InnoDB采用Next Key Lock解決幻讀(Phantom Problem)。對(duì)一個(gè)范圍加X鎖，從而這個(gè)范圍不允許插入，所以避免了幻讀。

此外，還可以用Next key lock實(shí)現(xiàn)唯一性檢查。如下，用戶通過索引查詢一個(gè)值，并對(duì)該行加一個(gè)S Lock；如果行不存在，鎖定一個(gè)范圍，新插入值也是唯一的。

SELECT * FROM TABLE WHERE COL = xxx LOCK IN SHARE MODE；

// 如果沒有找到任何行

INSERT INTO TABLE VALUES(...)

間隙鎖加鎖原則：

1、加鎖的基本單位是 NextKeyLock，是前開后閉區(qū)間。

2、查找過程中訪問到的對(duì)象才會(huì)加鎖。

3、索引上的等值查詢，給唯一索引加鎖的時(shí)候，NextKeyLock退化為行鎖。

4、索引上的等值查詢，向右遍歷時(shí)且最后一個(gè)值不滿足等值條件的時(shí)候，NextKeyLock退化為間隙鎖。

5、唯一索引上的范圍查詢會(huì)訪問到不滿足條件的第一個(gè)值為止。

自增鎖

AUTOINC 鎖又叫自增鎖(一般簡(jiǎn)寫成 AI 鎖)，是一種表鎖，當(dāng)表中有自增列(AUTOINCREMENT)時(shí)出現(xiàn)。

當(dāng)插入表中有自增列時(shí)，數(shù)據(jù)庫(kù)需要自動(dòng)生成自增值，它會(huì)先為該表加 AUTOINC 表鎖，阻塞其他事務(wù)的插入操作，這樣保證生成的自增值肯定是唯一的。AUTOINC 鎖具有如下特點(diǎn)：

AUTO_INC 鎖互不兼容，也就是說同一張表同時(shí)只允許有一個(gè)自增鎖；

自增值一旦分配了就會(huì) +1，如果事務(wù)回滾，自增值也不會(huì)減回去，所以自增值可能會(huì)出現(xiàn)中斷的情況。

顯然，AUTOINC 表鎖會(huì)導(dǎo)致并發(fā)插入的效率降低，為了提高插入的并發(fā)性，MySQL 從 5.1.22 版本開始，引入了一種可選的輕量級(jí)鎖(mutex)機(jī)制來代替 AUTOINC 鎖，可以通過參數(shù) innodbautoinclockmode 來靈活控制分配自增值時(shí)的并發(fā)策略。具體可以參考 MySQL 的 AUTOINCREMENT Handling in InnoDB 一文

死鎖

概念：死鎖是指兩個(gè)或兩個(gè)以上的事務(wù)執(zhí)行過程中，因爭(zhēng)奪資源而造成的一種互相等待的現(xiàn)象。

解決死鎖第一種方法：超時(shí)，然后對(duì)事務(wù)回滾

缺點(diǎn)：若超時(shí)的事務(wù)所占權(quán)重比較大，如事務(wù)更新了很多行，占用了較多的undo log，這時(shí)采用FIFO方式就不合適了，因?yàn)榛貪L這個(gè)事務(wù)的時(shí)間相對(duì)另一個(gè)事務(wù)所占用的時(shí)間可能會(huì)多很多。

wait-for graph等待圖方式進(jìn)行死鎖檢測(cè)

InnoDB采用的方式。

wait-for graph要求數(shù)據(jù)庫(kù)保存兩種信息，通過下面兩個(gè)鏈表構(gòu)造出一張圖，如果這個(gè)圖中存在回路，就代表存在死鎖，因此資源間發(fā)生相互等待。

鎖的信息鏈表

事務(wù)等待鏈表

如下圖示例，事務(wù)等待鏈表有4個(gè)事務(wù)，而右邊鎖信息鏈表中，row1中事務(wù)t1要等待事務(wù)t2資源，所以在下wait-for graph圖中就有一條t1指向t2的箭頭；而row2中tt2、t3需要等待t1中占用row2資源，故t2、t3各有個(gè)箭頭指向t1(t1、t4兩個(gè)S鎖兼容)。依次最后得到下面的圖。

可以發(fā)現(xiàn)(t1, t2)存在回路，因此存在死鎖。

所以wait-for graph是一種主動(dòng)的死鎖檢查機(jī)制，若存在死鎖，選擇回滾undo量最小的事務(wù)。(wait-for graph采用圖的深度優(yōu)先算法)

總結(jié)

以上是生活随笔為你收集整理的深入理解mysql系列_深入理解MySQL系列之锁的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。