封鎖

封鎖粒度

MySQL 中提供了兩種封鎖粒度：行級鎖以及表級鎖。（還有一種折中的鎖叫 頁級鎖 BDB支持）

應該盡量只鎖定需要修改的那部分數據，而不是所有的資源。鎖定的數據量越少，發生鎖爭用的可能就越小，系統的并發程度就越高。

但是加鎖需要消耗資源，鎖的各種操作（包括獲取鎖、釋放鎖、以及檢查鎖狀態）都會增加系統開銷。因此封鎖粒度越小，系統開銷就越大。

在選擇封鎖粒度時，需要在鎖開銷和并發程度之間做一個權衡。

?

封鎖類型

1. 讀寫鎖

• 排它鎖（Exclusive），簡寫為 X 鎖，又稱寫鎖。
• 共享鎖（Shared），簡寫為 S 鎖，又稱讀鎖。

有以下兩個規定：

• 一個事務對數據對象 A 加了 X 鎖，就可以對 A 進行讀取和更新。加鎖期間其它事務不能對 A 加任何鎖，即其他事務不能讀，不能寫。
• 一個事務對數據對象 A 加了 S 鎖，可以對 A 進行讀取操作，但是不能進行更新操作。加鎖期間其它事務能對 A 加 S 鎖，但是不能加 X 鎖。

鎖的兼容關系如下：

-XS

X	×	×
S	×	√

2. 意向鎖

使用意向鎖（Intention Locks）可以更容易地支持多粒度封鎖。

在存在行級鎖和表級鎖的情況下，事務 T 想要對表 A 加 X 鎖，就需要先檢測是否有其它事務對表 A 或者表 A 中的任意一行加了鎖，那么就需要對表 A 的每一行都檢測一次，這是非常耗時的。

意向鎖在原來的 X/S 鎖之上引入了 IX/IS，IX/IS 都是表鎖，用來表示一個事務想要在表中的某個數據行上加 X 鎖或 S 鎖。有以下兩個規定：

• 一個事務在獲得某個數據行對象的 S 鎖之前，必須先獲得表的 IS 鎖或者更強的鎖；
• 一個事務在獲得某個數據行對象的 X 鎖之前，必須先獲得表的 IX 鎖。

通過引入意向鎖，事務 T 想要對表 A 加 X 鎖，只需要先檢測是否有其它事務對表 A 加了 X/IX/S/IS 鎖，如果加了就表示有其它事務正在使用這個表或者表中某一行的鎖，因此事務 T 加 X 鎖失敗。

各種鎖的兼容關系如下：

-XIXSIS

X	×	×	×	×
IX	×	√	×	√
S	×	×	√	√
IS	×	√	√	√

解釋如下：

• 任意 IS/IX 鎖之間都是兼容的，因為它們只是表示想要對表加鎖，而不是真正加鎖；
• S 鎖只與 S 鎖和 IS 鎖兼容，也就是說事務 T 想要對數據行加 S 鎖，其它事務可以已經獲得對表或者表中的行的 S 鎖。

封鎖協議

1. 三級封鎖協議

一級封鎖協議

事務 T 要修改數據 A 時必須加 X 鎖，直到 T 結束才釋放鎖。

可以解決丟失修改問題，因為不能同時有兩個事務對同一個數據進行修改，那么事務的修改就不會被覆蓋。

T1T2

lock-x(A)	?
read A=20	?
?	lock-x(A)
?	wait
write A=19	.
commit	.
unlock-x(A)	.
?	obtain
?	read A=19
?	write A=21
?	commit
?	unlock-x(A)

二級封鎖協議

在一級的基礎上，要求讀取數據 A 時必須加 S 鎖，讀取完馬上釋放 S 鎖。

可以解決讀臟數據問題，因為如果一個事務在對數據 A 進行修改，根據 1 級封鎖協議，會加 X 鎖，那么就不能再加 S 鎖了，也就是不會讀入數據。

T1T2

lock-x(A)	?
read A=20	?
write A=19	?
?	lock-s(A)
?	wait
rollback	.
A=20	.
unlock-x(A)	.
?	obtain
?	read A=20
?	unlock-s(A)
?	commit

三級封鎖協議

在二級的基礎上，要求讀取數據 A 時必須加 S 鎖，直到事務結束了才能釋放 S 鎖。

可以解決不可重復讀的問題，因為讀 A 時，其它事務不能對 A 加 X 鎖，從而避免了在讀的期間數據發生改變。

T1T2

lock-s(A)	?
read A=20	?
?	lock-x(A)
?	wait
read A=20	.
commit	.
unlock-s(A)	.
?	obtain
?	read A=20
?	write A=19
?	commit
?	unlock-X(A)

2. 兩段鎖協議

加鎖和解鎖分為兩個階段進行。

可串行化調度是指，通過并發控制，使得并發執行的事務結果與某個串行執行的事務結果相同。

事務遵循兩段鎖協議是保證可串行化調度的充分條件。例如以下操作滿足兩段鎖協議，它是可串行化調度。

lock-x(A)...lock-s(B)...lock-s(C)...unlock(A)...unlock(C)...unlock(B)

但不是必要條件，例如以下操作不滿足兩段鎖協議，但是它還是可串行化調度。

lock-x(A)...unlock(A)...lock-s(B)...unlock(B)...lock-s(C)...unlock(C)

MySQL 隱式與顯示鎖定

MySQL 的 InnoDB 存儲引擎采用兩段鎖協議，會根據隔離級別在需要的時候自動加鎖，并且所有的鎖都是在同一時刻被釋放，這被稱為隱式鎖定。

InnoDB 也可以使用特定的語句進行顯示鎖定：

SELECT ... LOCK In SHARE MODE; SELECT ... FOR UPDATE;

---

?當問到數據庫中的鎖機制的時候？
從封鎖的粒度、類型、協議！！！結合不同的數據庫引擎來說！

我們可以這樣說：

1，數據庫中的鎖機制，從鎖的粒度來劃分，分為行級鎖和表級鎖（定義，開銷，鎖爭用情況，并發程度）。

MYISAM支持表級鎖，INNODB既支持表級鎖，又支持行級鎖，默認行級鎖

2，從鎖的類型劃分分為：讀寫鎖（X鎖和S鎖-------->（定義，規則））和意向鎖（為什么有意向鎖？每一次加鎖都需要查詢這個資源是否被加鎖，而這一個過程很耗時，所以添加意向鎖來表示我即將要對某一個資源進行加鎖操作！那我們要對某一資源進行加鎖時只需要看有沒有加意向鎖！）

?3，封鎖協議：三級鎖協議+兩段鎖協議

4，數據庫的死鎖問題：

行級鎖與死鎖

MyISAM中是不會產生死鎖的，因為MyISAM總是一次性獲得所需的全部鎖（表級鎖），要么全部滿足，要么全部等待。而在InnoDB中，鎖是逐步獲得的，就造成了死鎖的可能。

在MySQL中，行級鎖并不是直接鎖記錄，而是鎖索引。索引分為主鍵索引和非主鍵索引兩種，如果一條sql語句操作了主鍵索引，MySQL就會鎖定這條主鍵索引；如果一條語句操作了非主鍵索引，MySQL會先鎖定該非主鍵索引，再鎖定相關的主鍵索引。 在UPDATE、DELETE操作時，MySQL不僅鎖定WHERE條件掃描過的所有索引記錄，而且會鎖定相鄰的鍵值，即所謂的next-key locking（間隙鎖）。

當兩個事務同時執行，一個鎖住了主鍵索引，在等待其他相關索引。另一個鎖定了非主鍵索引，在等待主鍵索引。這樣就會發生死鎖。

發生死鎖后，InnoDB一般都可以檢測到，并使一個事務釋放鎖回退，另一個獲取鎖完成事務。

---

有多種方法可以避免死鎖，這里只介紹常見的三種

1、如果不同程序會并發存取多個表，盡量約定以相同的順序訪問表，可以大大降低死鎖機會。

2、在同一個事務中，盡可能做到一次鎖定所需要的所有資源，減少死鎖產生概率；

3、對于非常容易產生死鎖的業務部分，可以嘗試使用升級鎖定顆粒度，通過表級鎖定來減少死鎖產生的概率；

下一篇博文講一下樂觀鎖和悲觀鎖

總結

以上是生活随笔為你收集整理的数据库的封锁的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。