MySQL技術內幕：Innodb存儲引擎

(間隙鎖目前理解的還不是很透徹，后面索引看完了再過來回顧一下間隙鎖)

第六章 鎖

一、Innodb存儲引擎中的鎖

1.鎖是數據庫區別于文件系統的一個關鍵特性，

2.兩種標準的行級鎖：

• 共享鎖(S Lock)：允許事務讀一行數據
• 排它鎖(X Lock)：允許事務刪除或更新一行數據

? S鎖與S鎖兼容，與X鎖不兼容：也就是如果事務t1獲取了行r的共享鎖，那么事務t2也想獲取行r的共享鎖是可以獲取到的(這種情況成為鎖兼容)，但是如果事務t3想獲取行r的排它鎖是不能獲取到的，必須釋放t1、t2釋放行r上的共享鎖(這種情況成為鎖不兼容)。

? X鎖與任何鎖都不兼容。

? S鎖與X鎖都是行鎖，兼容指的是對于同一行(row)數據來說。

? 表：排它鎖與共享鎖的兼容性

XS

X	不兼容	不兼容
S	不兼容	兼容

Innodb支持多粒度鎖定，這種鎖定允許事務在行級鎖和表級鎖同時存在，為了支持在不同粒度上進行加鎖操作，Innodb支持一種額外的鎖方式，叫做意向鎖。

3.意向鎖：

意向鎖的含義,在innodb中如果對表加了意向鎖，說明表中的行在加鎖的狀態，對任意行加鎖前必須先對他的表加上意向鎖，

意向鎖分為:

• 意向共享鎖：事務想獲得一張表中某幾行的共享鎖
• 意向排它鎖：事務想獲得一張表中某幾行的排它鎖

由于innodb存儲引擎支持的行級鎖，因此意向鎖其實不會阻塞除全表掃描以外的任何請求。故表級意向鎖與表級鎖的兼容性如表

ISIXSX

IS	兼容	兼容	兼容	不兼容
IX	兼容	兼容	不兼容	不兼容
S	兼容	不兼容	兼容	不兼容
X	不兼容	不兼容	不兼容	不兼容

PS：上述表格中的IS、IX、S、X都表示的是表級鎖，S、X并不是書上 所說的表級鎖。

4.一致性非鎖定讀（和隔離級別有關）

如果讀取的行正在執行delete或者update操作，這時讀取操作不會因此去等待行上鎖的釋放，相反，Innodb會去讀取行的一個快照數據。之所以成為非鎖定讀，是因為不需要等待行上的X鎖釋放。

快照數據：是指改行之前的版本的數據，該實現是通過undo段來完成的，而undo用來在事務回滾數據。因此快照本身并沒有額外的開銷。

因此一致性非鎖定讀提高了并發性，Innodb存儲引擎是默認的讀取方式，即讀取不會占用和等待表上的鎖，但是在不同的隔離級別下，讀取的方式是不同的，并不是每個事物的隔離級別都采用一致性非鎖定讀的，并且即使采用一致性非鎖定度讀取的快照副本也是不一樣的。

在事務的隔離級別Read Committed(讀已提交)和Repeatable Read(可重復度)下，Innodb采用一致性非鎖定讀；Read Committed 下是讀取被鎖定行的最新一份的快照數據，而Repeatable Read下是讀取事務開始時的行數據版本。

例子：Read Committed下：事務1開啟查詢id=1，事務二開啟將id=1的值改變為了id=2；事務1再一次讀id=1,獲取的結果為Empty,因為讀已提交是讀取最新一份的快照數據。

Repeatable Read下：事務1開啟查詢id=1，事務二開啟將id=1的值改變為了id=2；事務1再一次讀id=1，獲取的結果是id=1，因為可重復度是會讀取事務開啟時的快照副本的數據。

ps：查看當前的隔離級別：select @@tx_isolation;

? 更改事務的隔離級別：set [ global | session ] transaction isolation level Read uncommitted | Read committed | Repeatable | Serializable; （global | session ：全局(已存在的不受影響)|當前窗口）

5.一致性鎖定讀

在某些情況下，用戶需要顯式地對數據庫讀取操作進行加鎖來保證數據邏輯的一致性，這就要求數據庫支持對讀操作的加鎖語句，即便是只讀。Innodb存儲引擎對于select語句支持兩種一致性鎖定讀操作：

• Select … For Update
• Select … Lock In Share Mode

Select … for update 對讀取的行記錄加一個X鎖，其他事物不能對已鎖定的行加任何鎖。

Select … Lock In Share Mode 對讀取的行記錄加一個S鎖，其他事物可以向被鎖定的行加S鎖，但如果加X鎖，則會被阻塞；

對于一致性非鎖定讀即使讀取的行已經加了select … for update也是可以讀取的，因為他讀取的快照數據。

另外一致性鎖定讀Select … For Update、Select … Lock In Share Mode必須在事務中使用才有用，當事務提交了，鎖也就被釋放了。

6.外鍵和鎖

外鍵主要用于完整的約束性檢查，在Innodb中對于一個外鍵列，如果沒有顯式地創建這個列的索引，Innodb存儲引擎就會對其加一個索引，因為這樣可以避免表鎖。

對于外鍵值的插入或更新，首先需要查詢父表中的記錄，即select父表。但是對于父表Select操作，不是使用的一致性非鎖定讀的方式，因為這樣會導致數據的不一致的問題，因此這時使用的是Select … Lock In Share Mode 方式，即主動對父表加S鎖，如果這時父表已經被上了X鎖，子表的操作會被阻塞。

例子：假設父表id與子表pid關聯，事務1刪除父表中id=1的行不提交會對id=1的行加X鎖，事務2要向子表中插入數據pid=1的數據，首先要Select父表id=1就會對id=1的行加S鎖，X鎖是排它鎖所以Select操作被阻塞，所以子表插入被阻塞。

鎖的算法

行鎖的三種算法

• Record Lock:單個行記錄上的鎖
• Gap Lock：間隙鎖，鎖定一個范圍，但不包含記錄本身
• Next-Key Lock：Gap Lock+Record Lock，鎖定一個范圍并包含記錄本身

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

Next-Key Lock：是結合了Gap Lock 和 Record Lock的一種鎖定算法，在Next-Key Lock算法下，Innodb對于行的查詢都采用這種鎖定算法，例如一個索引有10,11,13,和20四個值，那么該索引可能被Next-Key Locking的區間為

(負無窮 - 10 ]

(10 - 11]

(11 - 13]

(13 - 20]

(20 - 正無窮)

除了Next-key Locking 還有previous-key locking，使用previous-key locking鎖住的區間為

(負無窮 - 10 )

[10 - 11)

[11 - 13)

[13 - 20)

[20 - 正無窮)

當查詢的索引含有唯一屬性時，Innodb存儲引擎會對Next-Key locking進行優化，將其降級為Record Lock，即僅鎖住索引本身，而不是范圍。

鎖引發的問題：

臟讀：事務讀取到了其他事物未提交的數據，違反了事務的隔離性。

不可重復讀：事務多次讀取到的數據不一樣，事務1第二次讀取的數據是其他事物DML操作后提交的數據，造成了同一個語句兩次讀取的數據不一致。(與臟讀的區別是不可重復讀讀取的數據是事務提交后的，臟讀讀取的是事務未提交的數據)

幻讀：在可重復度的隔離級別下：事務使用當前讀(for update，直接讀讀取的是開啟時的undo快照數據)后一次查詢查到了前一次沒有查到的行，造成了幻讀現象，使用間隙鎖解決。

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的innodb存储引擎 - 锁的全部內容，希望文章能夠幫你解決所遇到的問題。

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