MySQL 中的鎖還是蠻多的，在之前的文章中，松哥和大家介紹過 MySQL 中的 MDL 鎖（爲什麼執行 alter 更新表要慎重？），今天我們再來看看 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！