sql中select * from t where c=5 for update排它鎖的示例分析

小編給大家分享一下sql中select * from t where c=5 for update排它鎖的示例分析，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

• RC隔離級別下，

• update產生的X鎖在不釋放的情況下，

• DELETE語句無法執行，

• 但是UPDATE語句能更新不符合之前X鎖的記錄。

• 不符合條件的會及時釋放行鎖，不必等事務結束時釋放；

• RC沒有間隙鎖的概念

• 對非索引字段更新，有個鎖全表記錄的過程，

• 而直接用索引列更新，只會鎖索引查找值和行。

• RR隔離級別下，為保證binlog記錄順序，

• 非索引更新會鎖住全表記錄，

• 且事務結束前不會對不符合條件記錄有逐步釋放的過程。

• DELETE和UPDATE語句都不能執行

版本5.7.13
rc模式下:
session 1:
begin;
select * from t where c=5 for update; 
session 2:
delete from t where c=10 --等待
session 3:
insert into t values(100001,8) --成功

session 4 : update t set c=100 where id=10  -- 成功
session 1:
commit
session 2:事務執行成功
rr模式下:
begin;
select * from t where c=5 for update; 
session 2:
delete from t where c=10 --等待
session 3:
insert into t values(100001,8) --等待

session 4 : update t set c=100 where id=10 --等待
session 1:
commit
session 2:事務執行成功
session 3：事務執行成功
從上面這兩個簡單的例子,可以大概看出上鎖的流程.
不管是rr模式還是rc模式,這條語句都會先在server層對表加上MDL S鎖,然后進入到引擎層。

rc模式下,由于數據量不大只有10W。通過實驗可以證明session 1上來就把該表的所有行都鎖住了。
導致其他事務要對該表的所有現有記錄做更新,是阻塞狀態。為什么insert又能成功?
說明rc模式下for update語句沒有上gap鎖,所以不阻塞insert對范圍加插入意向鎖,所以更新成功。
session 1commit后,session 2執行成功。表明所有行的x鎖是在事務提交完成以后才釋放。

rr模式下,session 1和session 2與rc模式下都一樣,說明rr模式下也對所有行上了X鎖。
唯一的區別是insert也等待了,是因為rr模式下對沒有索引的更新,聚簇索引上的所有記錄，都被加上了X鎖。其次，聚簇索引每條記錄間的間隙(GAP)，也同時被加上了GAP鎖。由于gap鎖阻塞了insert要加的插入意向鎖,導致insert也處于等待狀態。只有當session 1 commit完成以后。session 1上的所有鎖才會釋放,S2,S3執行成功

由于例子中的數據量還比較小,如果數據量達到千萬級別,就比較直觀的能看出,上鎖是逐行上鎖的一個過程.掃描一條上一條,直到所有行掃描完,rc模式下對所有行上x鎖。rr模式下不僅對所有行上X鎖,還對所有區間上gap鎖.直到事務提交或者回滾完成后,上的鎖才會被釋放。

以上是“sql中select * from t where c=5 for update排它鎖的示例分析”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！