Mysql中S 鎖和 X 鎖的區別

導讀	S 鎖，英文為 Shared Lock，中文譯作共享鎖，有時候我們也稱之為讀鎖，即 Read Lock。S 鎖之間是共享的，或者說是互不阻塞的。

MySQL 中的鎖還是蠻多的，在之前的文章中，松哥和大家介紹過 MySQL 中的 MDL 鎖，今天我們再來看看 MySQL 中比較重要的兩個鎖：S 鎖和 X 鎖。

S 鎖，英文為 Shared Lock，中文譯作共享鎖，有時候我們也稱之為讀鎖，即 Read Lock。S 鎖之間是共享的，或者說是互不阻塞的。

當事務讀取一條記錄時，需要先獲取該記錄的 S 鎖。

舉個例子：

事務 T1 對記錄 R1 加上了 S 鎖，那麼事務 T1 可以讀取 R1 這一行記錄，但是不能修改 R1，其他事務 T2 可以繼續對 R1 新增 S 鎖，但是不能新增 X 鎖，只有當 R1 上面的 S 鎖釋放了，才能加上 X 鎖。

舉一個加 S 鎖的例子，如下圖：

此時，對於 id=1 的這條記錄，只能讀取不能修改了。假設在另外一個事務 T 中，執行如下 SQL 是沒問題的，因為 S 鎖是共享鎖，S 鎖和 S 鎖之間是相容的：

select * from user where id=1 lock in share mode;

但是如果執行如下 SQL 則會被阻塞，因為修改資料需要獲取 X 鎖，而 S 鎖和 X 鎖不相容：

update user set username='javaboy' where id=1;

上面這個更新語句內部會獲取 X 鎖，對於一些手動新增了 X 鎖的查詢語句，也會阻塞，例如下面這個：

可以看到，這個 SQL 執行之後就被阻塞了。

X 鎖，英文為 Exclusive Lock，中文譯作排他鎖，有時候我們也稱之為寫鎖，即 Write Lock。如同它的名字，X 鎖是具有排他性的，即一個寫鎖會阻塞其他的 X 鎖和 S 鎖。

當事務需要修改一條記錄時，需要先獲取該記錄的 X 鎖。

舉個例子：

事務 T1 對記錄 R1 加上了 X 鎖，那麼事務 T1 即可以讀取 R1 也可以修改 R1，而其他事務則不能對 R1 再新增任何鎖，直到 T1 釋放了 R1 上的鎖。

如上文圖示，鎖定讀的格式是這樣的：

select .... for update;

由上面這兩種鎖，又引申出來兩種讀：

快照讀(SnapShot Read)是一種一致性不加鎖的讀，是 InnoDB 儲存引擎併發如此之高的核心原因之一。

在可重複讀的隔離級別下，事務啟動的時候，就會針對當前庫拍一個照片(快照)，快照讀讀取到的資料要麼就是拍照時的資料，即事務開啟那一瞬間資料庫中的資料，要麼就是當前事務自身插入/修改過的資料。

我們日常所用的不加鎖的查詢，都屬於快照讀，這個我就不演示了。

與快照讀相對應的就是當前讀，當前讀就是讀取最新資料，而不是歷史版本的資料，換言之，在可重複讀隔離級別下，如果使用了當前讀，也可以讀到別的事務已提交的資料。

松哥舉個例子：

MySQL 事務開啟兩個會話 A 和 B。

首先在 A 會話中開啟事務並查詢 id 為 1 的記錄：

接下來我們在 B 會話中對 id 為 1 的資料進行修改，如下：

注意 B 會話不要開啟事務或者開啟了及時提交事務，否則 update 語句佔用一把排他鎖會導致一會在 A 會話中用鎖時發生阻塞。

接下來，回到 A 會話中繼續做查詢操作，如下：

可以看到，A 會話中第一個查詢是快照讀，讀取到的是當前事務開啟時的資料狀態，後面兩個查詢則是當前讀，讀取到了當前最新的資料(B 會話中修改後的資料)。

好啦，一個小小的知識點，日積月累，fighting!

原文來自：