共计 1427 个字符，预计需要花费 4 分钟才能阅读完成。
| 导读 | 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!
