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

1. S 鎖

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 執行之后就被阻塞了。

2. X 鎖

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

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

舉個例子：

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

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

select .... for update;

3. 當前讀與快照讀

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

3.1 快照讀

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

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

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

3.2 當前讀

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

松哥舉個例子：

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

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

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

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

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

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

4. 小結

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