Lock鎖的原理是什么

本篇內(nèi)容介紹了“Lock鎖的原理是什么”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！

前提

MySQL中的行級鎖,表級鎖,頁級鎖中介紹過，行級鎖是Mysql中鎖定粒度最細的一種鎖，行級鎖能大大減少數(shù)據(jù)庫操作的沖突。行級鎖分為共享鎖和排他鎖兩種，本文將詳細介紹共享鎖及排他鎖的概念、使用方式及注意事項等。

加鎖目的

數(shù)據(jù)庫是一個多用戶使用的共享資源。當多個用戶并發(fā)地存取數(shù)據(jù)時，在數(shù)據(jù)庫中就會產(chǎn)生多個事務(wù)同時存取同一數(shù)據(jù)的情況。若對并發(fā)操作不加控制就可能會讀取和存儲不正確的數(shù)據(jù)，破壞數(shù)據(jù)庫的一致性。

鎖是用于管理對公共資源的并發(fā)控制。也就是說在并發(fā)的情況下，會出現(xiàn)資源競爭，所以需要加鎖。加鎖解決了 多用戶環(huán)境下保證數(shù)據(jù)庫完整性和一致性。

Lock的對象是事務(wù)，用來鎖定的是數(shù)據(jù)庫中的對象，如表、頁、行。并且一般lock的對象僅在事務(wù)commit或rollback后進行釋放（不同事務(wù)隔離級別釋放的時間可能不同）。

死鎖

死鎖是并發(fā)系統(tǒng)中常見的問題，同樣也會出現(xiàn)在數(shù)據(jù)庫MySQL的并發(fā)讀寫請求場景中。當兩個及以上的事務(wù)，雙方都在等待對方釋放已經(jīng)持有的鎖或因為加鎖順序不一致造成循環(huán)等待鎖資源，就會出現(xiàn)“死鎖”。常見的報錯信息為 ” Deadlock found when trying to get lock... ”。

死鎖場景

舉例來說A事務(wù)持有X1鎖 ，申請 X2 鎖，B事務(wù)持有 X2 鎖，申請 X1 鎖。A 和 B 事務(wù)持有鎖并且申請對方持有的鎖進入循環(huán)等待，就造成了死鎖。

InnoDB 鎖類型

為了分析死鎖，我們有必要對 InnoDB 的鎖類型有一個了解。

MySQL InnoDB引擎實現(xiàn)了標準行級別鎖：共享鎖( S lock ) 和排他鎖 ( X lock )

• 不同事務(wù)可以同時對同一行記錄加S鎖。

• 如果一個事務(wù)對某一行記錄加 X 鎖，其他事務(wù)就不能加 S 鎖或者 X 鎖，從而導致鎖等待。

如果事務(wù)T1持有行r的S鎖，那么另一個事務(wù) T2 請求r的鎖時，會做如下處理：

• T2 請求 S 鎖立即被允許，結(jié)果 T1 T2 都持有 r 行的 S 鎖

• T2 請求 X 鎖不能被立即允許

如果T1持有r的 X 鎖，那么T2請求r的X、S鎖都不能被立即允許，T2 必須等待 T1 釋放 X 鎖才可以，因為 X 鎖與任何的鎖都不兼容。共享鎖和排他鎖的兼容性如下所示：

間隙鎖(gap lock)

間隙鎖鎖住一個間隙以防止插入。假設(shè)索引列有2, 4, 8 三個值，如果對 4 加鎖，那么也會同時對(2,4)和(4,8)這兩個間隙加鎖。其他事務(wù)無法插入索引值在這兩個間隙之間的記錄。

但是，間隙鎖有個例外:

如果索引列是唯一索引，只會鎖住這條記錄(只加行鎖)，而不會鎖住間隙。 對于聯(lián)合索引且是唯一索引，如果 where 條件只包括聯(lián)合索引的一部分，那么依然會加間隙鎖。

產(chǎn)生間隙的條件

1. 使用普通索引鎖定；

2. 使用多列唯一索引；

3. 使用唯一索引鎖定多行記錄。

next-key lock（Record Lock + Gap Lock 臨鍵鎖）

next-key lock 實際上就是 行鎖+這條記錄前面的 gap lock 的組合。假設(shè)有索引值10,11,13和 20,那么可能的 next-key lock 包括:

- (負無窮,10]
- (10,11]
- (11,13]
- (13,20]
- (20,正無窮)

在RR隔離級別下，InnoDB 使用 next-key lock 主要是防止幻讀問題產(chǎn)生。

臨鍵鎖，是記錄鎖與間隙鎖的組合，它的封鎖范圍，既鎖住記錄本身還鎖住索引之間的間隙。

 注：臨鍵鎖的主要目的，也是為了避免幻讀(Phantom Read)。如果把事務(wù)的隔離級別降級為RC，臨鍵鎖則也會失效。

意向鎖( Intention lock )

InnoDB為了支持多粒度的加鎖，允許行鎖和表鎖同時存在。為了支持在不同粒度上的加鎖操作，InnoDB 支持了額外的一種鎖方式，稱之為意向鎖( Intention Lock )，意向鎖是 InnoDB 自動加的,不需用戶干預。

意向鎖是將鎖定的對象分為多個層次，意向鎖意味著事務(wù)希望在更細粒度上進行加鎖。

意向鎖分為兩種：

• 意向共享鎖( IS )：事務(wù)有意向?qū)Ρ碇械哪承┬屑庸蚕礞i：（事務(wù)務(wù)打算給數(shù)據(jù)行加行共享鎖，事務(wù)在給一個數(shù)據(jù)行加共享鎖前必須先取得該表的 IS 鎖）

• 意向排他鎖( IX )：事務(wù)有意向?qū)Ρ碇械哪承┬屑优潘i：（事務(wù)打算給數(shù)據(jù)行加行排他鎖，事務(wù)在給一個數(shù)據(jù)行加排他鎖前必須先取得該表的 IX 鎖）

由于InnoDB存儲引擎支持的是行級別的鎖，因此意向鎖其實不會阻塞除全表掃描以外的任何請求。表級意向鎖與行級鎖的兼容性如下所示： 意向鎖有什么用？ 主要作用是處理行鎖和表鎖之間的矛盾，能夠顯示“某個事務(wù)正在某一行上持有了鎖，或者準備去持有鎖” 當我們需要加一個排他鎖時，需要根據(jù)意向鎖去判斷表中有沒有數(shù)據(jù)行被鎖定

比如事務(wù)A要在一個表上加S鎖，如果表中的一行已被事務(wù)B加了X鎖，那么該鎖的申請也應(yīng)被阻塞。如果表中的數(shù)據(jù)很多，逐行檢查鎖標志的開銷將很大，系統(tǒng)的性能將會受到影響。為了解決這個問題，可以在表級上引入新的鎖類型來表示其所屬行的加鎖情況，這就引出了“意向鎖”的概念。

舉個例子，如果表中記錄1億，事務(wù)A把其中有幾條記錄上了行鎖了，這時事務(wù)B需要給這個表加表級鎖，如果沒有意向鎖的話，那就要去表中查找這一億條記錄是否上鎖了。

如果存在意向鎖，那么假如事務(wù)Ａ在更新一條記錄之前，先加意向鎖，再加Ｘ鎖，事務(wù)B先檢查該表上是否存在意向鎖，存在的意向鎖是否與自己準備加的鎖沖突，如果有沖突，則等待直到事務(wù)Ａ釋放，而無須逐條記錄去檢測。 事務(wù)Ｂ更新表時，其實無須知道到底哪一行被鎖了，它只要知道反正有一行被鎖了就行了。

行鎖的算法

Record Lock（單行記錄）

單條索引上加鎖，record lock 永遠鎖的是索引，而非數(shù)據(jù)本身，如果innodb表中沒有索引，那么會自動創(chuàng)建一個隱藏的聚集索引，鎖住的就是這個聚集索引。

當一條sql沒有走任何索引時，那么將會在每一條聚集索引后面加X鎖，這個類似于表鎖，但原理上和表鎖應(yīng)該是完全不同的。

記錄鎖的條件

命中單行記錄并且命中的條件字段是唯一索引或者主索引； update user_info set name=’張三’ where id=1; //這里的id是唯一索引,使用了Record Lock

Record Lock總是會去鎖住索引記錄，如果InnoDB存儲引擎表在建立的時候沒有設(shè)置任何一個索引，那么這時InnoDB存儲引擎會使用隱式的主鍵來進行鎖定。

插入意向鎖( Insert Intention lock )

插入意向鎖是在插入一行記錄操作之前設(shè)置的一種間隙鎖，這個鎖釋放了一種插入方式的信號，即多個事務(wù)在相同的索引間隙插入時如果不是插入間隙中相同的位置就不需要互相等待。假設(shè)某列有索引值2，6，只要兩個事務(wù)插入位置不同(如事務(wù) A 插入3，事務(wù) B 插入4)，那么就可以同時插入。

鎖模式兼容矩陣

橫向是已持有鎖，縱向是正在請求的鎖：

“Lock鎖的原理是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！