這張圖本人覺得總結(jié)得挺好的，在一般的互聯(lián)網(wǎng)項目中，基本上用的都是Innodb引擎，一般只涉及到的都是行級鎖，但是如果sql語句中不帶索引進行操作，可能會導致鎖表，這是不推薦的，性能非常低，可能會導致全表掃描等，行鎖的具體實現(xiàn)算法有以下幾種mysql特有的鎖：
創(chuàng)新互聯(lián)建站專業(yè)為企業(yè)提供大方網(wǎng)站建設(shè)、大方做網(wǎng)站、大方網(wǎng)站設(shè)計、大方網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計與制作、大方企業(yè)網(wǎng)站模板建站服務，十載大方做網(wǎng)站經(jīng)驗，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡(luò)服務。
Record Lock(記錄鎖):單個行記錄的鎖,一般是唯一索引或者主鍵上的加鎖
Gap Lock(間隙鎖):鎖定一個區(qū)間，但是不包括自身，開區(qū)間的鎖，RR級別才會有間隙鎖，間隙鎖的唯一目的是防止區(qū)間數(shù)據(jù)的插入，所以間隙鎖與間隙鎖之間是不會相互阻塞的
Next-key Lock(臨鍵鎖):與間隙鎖的區(qū)別是包括自身，是左開右閉區(qū)間，RR級別才會有
加鎖規(guī)則里面，包含了兩個“原則”、兩個“優(yōu)化”和一個“bug”。
原則 1：加鎖的基本單位是 next-key lock，希望你還記得，next-key lock 是前開后閉區(qū)間。
原則 2：查找過程中訪問到的對象才會加鎖。
優(yōu)化 1：索引上的等值查詢，給唯一索引加鎖的時候，next-key lock 退化為行鎖。
優(yōu)化 2：索引上的等值查詢，向右遍歷時且最后一個值不滿足等值條件的時候，next-key lock 退化為間隙鎖。
一個 bug：唯一索引上的范圍查詢會訪問到不滿足條件的第一個值為止。
舉例來說明上述的原則：
建表
插入數(shù)據(jù)：
INSERT INTO t ( id , c , d ) VALUES (0, 0, 0);
INSERT INTO t ( id , c , d ) VALUES (5, 5, 10);
INSERT INTO t ( id , c , d ) VALUES (10, 10, 10);
INSERT INTO t ( id , c , d ) VALUES (15, 15, 15);
INSERT INTO t ( id , c , d ) VALUES (20, 20, 20);
INSERT INTO t ( id , c , d ) VALUES (25, 25, 25);
例子1：鎖表
因為d字段上沒有建索引，所以涉及該字段的查詢加鎖會鎖住整個表
因為d字段上面沒有建立索引，所以事務1執(zhí)行后會導致整個表被鎖，后面所有的操作都會在等待整個表鎖被釋放
例子2：主鍵/唯一索引 記錄鎖
id字段為主鍵，而且事務1查詢命中了唯一的記錄，默認是加Next-key Lock，區(qū)間是（0，5]，但是根據(jù)優(yōu)化1，唯一索引/主鍵上的等值查詢，會退化為行鎖，所以只會鎖5這個記錄。
例子3：主鍵/唯一索引上的間隙鎖
由于表 t 中沒有 id=7 的記錄，所以用我們上面提到的加鎖規(guī)則判斷一下的話：根據(jù)原則 1，加鎖單位是 next-key lock，事務1加鎖范圍就是 (5,10]；同時根據(jù)優(yōu)化 2，這是一個等值查詢 (id=7)，而 id=10 不滿足查詢條件，next-key lock 退化成間隙鎖，因此最終加鎖的范圍是 (5,10)，所以事務2會阻塞，事務3執(zhí)行成功。
例子4：普通索引上的間隙鎖
c字段是普通索引，事務1執(zhí)行時默認是對區(qū)間（0,5]加間隙鎖，根據(jù)優(yōu)化2，非唯一索引/主鍵會繼續(xù)向右遍歷，找到10，所以最終的加鎖為（0，5]的Next-Key鎖+(5，10)的間隙鎖，所以事務2阻塞，事務3成功。
例子5：間隙鎖與行鎖
事務1默認的Next-Key鎖區(qū)間是(0，5],根據(jù)優(yōu)化2會向右遍歷，找到不滿足查詢條件的10，退化成間隙鎖，所以事務1的鎖是（0，5]的Next-Key鎖+(5，10)的間隙鎖，這兩個鎖與行鎖是沖突的，而事務2申請的Next-Key鎖是和事務1一樣，但是c=5的行鎖與事務1沖突，所以產(chǎn)生了阻塞，如果改為update t set d=1000 where c=6;因為此時產(chǎn)生的間隙鎖為（5，10），而間隙鎖與間隙鎖是不沖突的，不會產(chǎn)生阻塞
例子6：lock in share mode鎖覆蓋索引
事務1存在覆蓋索引的情況，不會去回表，lock in share mode這種情況下只會鎖c字段索引，而事務2是對主鍵加行鎖，所以兩者不存在沖突。
例子7：主鍵/唯一索引上的范圍查詢
開始執(zhí)行的時候，要找到第一個 id=10 的行，因此本該是 Next-Key Lock(5,10]，根據(jù)優(yōu)化 1， 主鍵 id 上的等值條件，退化成行鎖，只加了 id=10 這一行的行鎖。范圍查找就往后繼續(xù)找，找到 id=15 這一行停下來，因此需要加 Next-Key Lock(10,15]，所以事務3是沖突的。
例子8：普通索引上的范圍查詢
開始執(zhí)行時，找到第一個滿足條件的行10，加鎖Next-Key Lock(5,10]，因為不是唯一索引，所以不會退化，繼續(xù)向后面找，找到15這一行停下來，因此需要加 Next-Key Lock(10,15]，因為是范圍查詢，所以鎖不會退化。
快照讀： 通過MVCC實現(xiàn)，該技術(shù)不僅可以保證innodb的可重復讀，而且可以防止幻讀，但是他讀取的數(shù)據(jù)雖然是一致的，但是數(shù)據(jù)是歷史數(shù)據(jù)。
簡單的select操作(不包括 select … lock in share mode, select … for update)
當前讀： 要做到保證數(shù)據(jù)是一致的，同時讀取的數(shù)據(jù)是最新的數(shù)據(jù),innodb提供了next-key lock，即gap鎖與行鎖結(jié)合來實現(xiàn)。
select … lock in share mode
select … for update
insert
update
delete
自己理解：
簡單的select是快照讀，快照讀實現(xiàn)可提交讀，可重復讀和幻讀是通過MVCC+ReadView實現(xiàn)的,而當前讀實現(xiàn)這幾種是通過鎖來實現(xiàn)的,為了說明具體原理,下面介紹下MVCC和ReadView概念，所以簡單的select是通過樂觀鎖實現(xiàn)的，當前讀是通過悲觀鎖實現(xiàn)的。
參考文章：
什么是幻讀？
幻讀指的是一個事務在前后兩次查詢同一個范圍的時候，后一次查詢看到了前一次查詢沒有看到的行。
首先快照讀是不存在幻讀的，只有當前讀（實時讀）才存在幻讀的問題。
幻讀有什么問題？
select ...for update語句就是將相應的數(shù)據(jù)行鎖住，但是如果存在幻讀，就把for update的語義破壞了。
如何解決幻讀？
產(chǎn)生幻讀的原因是，行鎖只能鎖住行，但是新插入記錄這個動作，要更新的是記錄之間的“間隙”。因此，為了解決幻讀問題，InnoDB只好引入新的鎖，也就是間隙鎖(Gap Lock)。間隙鎖和行鎖合稱 next-key lock ， 每個next-key lock是前開后閉區(qū)間 。
總結(jié)
一、定義
1、幻讀MYSQL官方叫法是Phantom Rows，意為鬼影行或者幻影行，請看官方定義：
The so-called phantom problem occurs within a transaction when the same query produces different sets of rows at different times. For example, if a [ SELECT ] is executed twice, but returns a row the second time that was not returned the first time, the row is a “phantom” row.
翻譯一下：
所謂的幻影行問題是指，在同一個事務中，同樣的查詢語句執(zhí)行多次，得到了不同的行結(jié)果集。
例如，如果同一個SELECT語句執(zhí)行了兩次，第二次執(zhí)行的時候比第一次執(zhí)行時多出一行，則該行就是所謂的幻影行。
2、幻讀與不可重復讀的區(qū)別
從官方的定義來看，幻讀的定義側(cè)重于多條記錄，就是記錄條數(shù)的變化，而不可重復讀側(cè)重于單條記錄數(shù)據(jù)的變化，這樣區(qū)分原因在于解決幻讀需要范圍鎖，解決不可重復讀只需要單條記錄加鎖
二、InnoDB的REPEATABLE READ級別
InnoDB支持由SQL1992標準描述的所有四個事務隔離級別，默認隔離級別是 REPEATABLE READ。
1、快照讀：
在RR模式下，第一次讀取會建立快照，后續(xù)查詢會讀取快照。
這意味著，如果在同一事務中發(fā)出多個普通[ SELECT ]（非鎖定）語句，則這些 [ SELECT ]語句的結(jié)果也是一致的。
2、[locking reads](鎖定讀取，又叫當前讀）
[ SELECT ]語句中使用 FOR UPDATE 或 FOR SHARE
3、行鎖
在RR模式下，使用當前讀以及 [ UPDATE ]和 [ DELETE ]語句會對數(shù)據(jù)記錄加行鎖，鎖定范圍取決于該語句使用的是具有唯一搜索條件的唯一索引還是范圍類型搜索條件。
三、InnoDB的READ COMMITTED級別
1、在RC模式下，每次讀取都會刷新快照，因此不能保證可重復讀
2、在RC模式下，使用當前讀以及 [ UPDATE ]和 [ DELETE ]語句會對數(shù)據(jù)記錄加行鎖，但是不會加范圍鎖，間隙鎖定僅用于外鍵約束檢查和重復鍵檢查。
3、由于禁用了間隙鎖定，因此可能會產(chǎn)生幻影行問題，因為其他會話可以在間隙中插入新行。
4、 對于[ UPDATE ]或 [ DELETE ]語句， InnoDB 僅對其更新或刪除的行持有鎖。MySQL評估 WHERE 條件后，將釋放不匹配行的記錄鎖 。這大大降低了死鎖的可能性，但是仍然可以發(fā)生。
5、對于[ UPDATE ]語句，如果某行已被鎖定，則 InnoDB 執(zhí)行“半一致”讀取，將最新提交版本的數(shù)據(jù)返回給MySQL，以便MySQL可以確定該行是否符合 WHERE 條件。如果該行匹配（必須更新），則MySQL會再次讀取該行，這一次 InnoDB 會將其鎖定或等待獲取鎖。
6、注意
從MySQL 8.0.22開始，DML操作（增刪改，通過聯(lián)接列表或子查詢）從MySQL授權(quán)表中讀取數(shù)據(jù)，但不對其進行修改，無論隔離級別如何，都不會在MySQL授權(quán)表上獲得讀取鎖。
有關(guān)更多信息，請參見 Grant Table Concurrency 。
四、樂觀鎖與悲觀鎖
1、樂觀鎖
在UPDATE的WHERE子句中加入版本信息來確定修改是否生效
使用樂觀鎖時仍然需要非常謹慎，因為RR是可重復讀的，在UPDATE之前讀取版本號，應該使用[當前讀]，不能使用[快照讀]
2、悲觀鎖
在UPDATE執(zhí)行前，SELECT后面加上FOR UPDATE來給記錄加鎖，保證記錄在UPDATE前不被修改。SELECT ... FOR UPDATE是加上了X鎖，也可以通過SELECT ... LOCK IN SHARE MODE加上S鎖，來防止其他事務對該行的修改。
3、無論是樂觀鎖還是悲觀鎖，使用的思想都是一致的，那就是當前讀。樂觀鎖利用當前讀判斷是否是最新版本，悲觀鎖利用當前讀鎖定行。
五、總結(jié)
1、RC級別沒有范圍鎖一定會導致不可重復讀和幻影行
2、RR級別安全性更高，實現(xiàn)可重復讀的方式為快照，如果需要最新數(shù)據(jù)可以選擇[當前讀]，因此RR級別是首選
3、不論RR還是RC級別，增、刪、改的操作都會進行一次[當前讀]操作，以此獲取最新版本的數(shù)據(jù)，并檢測是否有重復的索引。
4、RR級別下，當前事務如果未發(fā)生更新操作(增刪改)，快照版本會保持不變，多次查詢讀取的快照是同一個
5、RR級別下，當前事務如果發(fā)生更新(增刪改)，會刷新快照，會導致不可重復讀和幻影行
6、RR級別下，使用當前讀，會刷新快照，會導致不可重復讀和幻影行
7、RR級別下，可以通過提交當前事務并在此之后發(fā)出新查詢來為查詢獲取更新的快照。
8、RR級別可以部分解決不可重復讀和幻讀問題
9、其實問題的關(guān)鍵是你的業(yè)務邏輯需要可重復讀還是最新數(shù)據(jù)
重慶分公司
重慶分公司
