[MySQL] 行级锁SELECT ... LOCK IN SHARE MODE 和 SELECT ... FOR UPDATE

太过爱你忘了你带给我的痛 2022-07-16 07:08 186阅读 0赞

## 一、译文 ##

翻译来自官方文档：[Locking Reads][]

If you query data and then insert or update related data within the same transaction, the regular SELECT statement does not give enough protection. Other transactions can update or delete the same rows you just queried. InnoDB supports two types of locking reads that offer extra safety:

如果你在查询数据，然后在同一个事务里插入或者修改相关的数据，常规的 select 语句不会提供足够的保护。其他的事务可以修改或者删除你正在查询的行。InnoDB 支持两种可以提供安全机制的读取锁：

*SELECT … LOCK IN SHARE MODE* sets a shared mode lock on any rows that are read. Other sessions can read the rows, but cannot modify them until your transaction commits. If any of these rows were changed by another transaction that has not yet committed, your query waits until that transaction ends and then uses the latest values.

SELECT … LOCK IN SHARE MODE 在读取的行上设置一个共享锁，其他的session可以读这些行，但在你的事务提交之前不可以修改它们。如果这些行里有被其他的还没有提交的事务修改，你的查询会等到那个事务结束之后使用最新的值。

For index records the search encounters, *SELECT … FOR UPDATE* locks the rows and any associated index entries, the same as if you issued an UPDATE statement for those rows. Other transactions are blocked from updating those rows, from doing SELECT … LOCK IN SHARE MODE, or from reading the data in certain transaction isolation levels. Consistent reads ignore any locks set on the records that exist in the read view. (Old versions of a record cannot be locked; they are reconstructed by applying undo logs on an in-memory copy of the record.)

索引搜索遇到的记录，SELECT … FOR UPDATE 会锁住行及任何关联的索引条目，和你对那些行执行 update 语句相同。其他的事务会被阻塞在对这些行执行 update 操作，获取共享锁，或从某些事务隔离级别读取数据等操作。一致性读([Consistent Nonlocking Reads][])会忽略在读取视图上的记录的任何锁。（旧版本的记录不能被锁定；它们通过应用撤销日志在记录的内存副本上时被重建。）

All locks set by LOCK IN SHARE MODE and FOR UPDATE queries are released when the transaction is committed or rolled back.

Note  
Locking of rows for update using SELECT FOR UPDATE only applies when autocommit is disabled (either by beginning transaction with START TRANSACTION or by setting autocommit to 0. If autocommit is enabled, the rows matching the specification are not locked.

所有被共享锁和排他锁查询所设置的锁都会在事务提交或者回滚之后被释放。

注:  
使用 SELECT FOR UPDATE 为 update 操作锁定行，只适用于 autocommit 被禁用（当使用 START TRANSACTION 开始事务或者设置 autocommit 为0时）。如果 autocommit 已启用，符合规范的行不会被锁定。

## 二、总结 ##

此处参考：[MySQL中的共享锁与排他锁][MySQL]

SELECT … LOCK IN SHARE MODE ：共享锁(S锁, share locks)。其他事务可以读取数据，但不能对该数据进行修改，直到所有的共享锁被释放。

如果事务对某行数据加上共享锁之后，可进行读写操作；其他事务可以对该数据加共享锁，但不能加排他锁，且只能读数据，不能修改数据。

SELECT … FOR UPDATE：排他锁(X锁, exclusive locks)。如果事务对数据加上排他锁之后，则其他事务不能对该数据加任何的锁。获取排他锁的事务既能读取数据，也能修改数据。

注：普通 select 语句默认不加锁，而CUD操作默认加排他锁。

## 三、验证 ##

注：使用 mysql 版本为 5.7.9，事务隔离级别为InnoDB默认隔离级别 可重复读(Repeated Read)。

对以下几种情况进行验证：

1.  当前事务获取共享锁后，可以读写，其他事务是否可以进行读写操作和获取共享锁；
2.  两个事务同时获取共享锁后，是否可以进行update操作；
3.  当前事务获取排他锁后，其他事务是否可以进行读写操作和获取共享锁；
4.  是否可对一条数据加多个排他锁；
5.  行锁和索引的关系；
6.  索引数据重复率太高会导致全表扫描；

1、当前事务获取共享锁后，可以读写，其他事务是否可以进行读写操作和获取共享锁：可以读，可以获取共享锁，不可以写

当前事务可以写：  
![这里写图片描述][20161011112100835]

事务1获取某行数据共享锁后，事务2更新该行阻塞:  
![这里写图片描述][20161011112135111]

事务1提交之后，事务2更新成功：  
![这里写图片描述][20161011112205033]

2、两个事务同时获取某行数据共享锁后，是否可以进行update操作：不可以

两个事务同时获取某行数据共享锁，事务1更新该行阻塞：  
![这里写图片描述][20161011111815640]

事务2提交之后，事务1更新成功：  
![这里写图片描述][20161011111851281]

3、当前事务获取某行数据排他锁后，其他事务是否可以对该行数据进行读写操作和获取共享锁：其他事务可以读，不可以获取共享锁，不可以写

可以读该行数据：  
![这里写图片描述][20161011110108966]

不可以获取该行数据共享锁：  
![这里写图片描述][20161011110141993]

不可以更新该行数据：  
![这里写图片描述][20161011110546097]

4、是否可对一条数据加多个排他锁：不可以  
![这里写图片描述][20161011105922430]

5、行锁和索引的关系：查询字段未加索引（主键索引、普通索引等）时，使用表锁

注：InnoDB行级锁基于索引实现。

未加索引时，两种行锁情况为（使用表锁）：  
\- 事务1获取某行数据共享锁，其他事务可以获取不同行数据的共享锁，不可以获取不同行数据的排他锁  
\- 事务1获取某行数据排他锁，其他事务不可以获取不同行数据的共享锁、排他锁

加索引后，两种行锁为（使用行锁）：

*  事务1获取某行数据共享锁，其他事务可以获取不同行数据的排他锁
 *  事务1获取某行数据排他锁，其他事务可以获取不同行数据的共享锁、排他锁

未加索引表结构：  
![这里写图片描述][20161011113416291]

未加索引，事务1获取某行数据共享锁，事务2获取不同行数据共享锁成功：  
![这里写图片描述][20161011114617561]

未加索引，事务1获取某行数据共享锁，事务2更新不同行数据阻塞：  
![这里写图片描述][20161011114640342]

未加索引，事务1获取某行数据排他锁，事务2获取不同行数据共享锁阻塞：  
![这里写图片描述][20161011113456117]

未加索引，事务1获取某行数据排他锁，事务2获取不同行数据排他锁阻塞：  
![这里写图片描述][20161012103627270]

加索引后表结构：  
![这里写图片描述][20161011113522511]

加索引后，事务1获取某行数据共享锁，事务2更新不同行数据成功：  
![这里写图片描述][20161011114653715]

加索引后，事务1获取某行数据排他锁，事务2获取不同行数据共享锁成功：  
![这里写图片描述][20161011113555309]

加索引后，事务1获取某行数据排他锁，事务2获取不同行数据排他锁成功：  
![这里写图片描述][20161012103234034]

6、索引数据重复率太高会导致全表扫描：当表中索引字段数据重复率太高，则MySQL可能会忽略索引，进行全表扫描，此时使用表锁。可使用 force index 强制使用索引。

表结构：

CREATE TABLE `room` ( `id` int(11) NOT NULL AUTO_INCREMENT, `uid` int(11) NOT NULL, `username` varchar(200) NOT NULL DEFAULT '', `state` varchar(255) NOT NULL DEFAULT '-1', `created_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `index_uid` (`uid`) USING BTREE ) ENGINE=InnoDB AUTO_INCREMENT=11 DEFAULT CHARSET=utf8

表数据：  
![这里写图片描述][20161027173942116]

获取 uid = ‘11’ 的数据的行锁并更新，但更新失败：  
![这里写图片描述][20161027174628056]

降低数据重复率，更新成功：  
![这里写图片描述][20161027175212183]

![这里写图片描述][20161027175221387]

强制使用索引，更新成功：force index(index\_uid)  
![这里写图片描述][20161027174800073]

注：此处如果使用表锁，为何其他事务可以获取排他锁？

答：由于使用 `force index` ，而 InnoDB 行级锁基于索引实现，因此此处使用的是行锁。

## 四、InnoDB 行锁类型简介 ##

参考：[Mysql中那些锁机制之InnoDB][Mysql_InnoDB]

InnoDB行锁的三种类型：

*  Record Lock：对索引项加锁，锁定符合条件的行。其他事务不能修改和删除加锁项；
 *  Gap Lock：对索引项之间的“间隙”加锁，锁定记录的范围，不包含索引项本身。其他事务不能再锁范围内插入数据；
 *  Next-key Lock: 锁定索引项本身和索引范围，即Record Lock 和 Gap Lock 的结合。可解决幻读问题。

[Locking Reads]: http://dev.mysql.com/doc/refman/5.7/en/innodb-locking-reads.html
[Consistent Nonlocking Reads]: http://dev.mysql.com/doc/refman/5.7/en/innodb-consistent-read.html
[MySQL]: http://www.hollischuang.com/archives/923
[20161011112100835]: /images/20220716/64d55a7b46d0437ba9995234afbc7181.png
[20161011112135111]: /images/20220716/226d42011a35442dbeabdd95d61a8590.png
[20161011112205033]: /images/20220716/2b2eb7480a8e4f78b1f0d92d920168af.png
[20161011111815640]: /images/20220716/034387f8ccf0457a93648c2d308f477d.png
[20161011111851281]: /images/20220716/41e9afdc628f4c23b39aed6b2267b837.png
[20161011110108966]: /images/20220716/d3bf8b9c53134836bfaeadfbb4fde8e4.png
[20161011110141993]: /images/20220716/922765fb384f4746b11a5972f9a95d63.png
[20161011110546097]: /images/20220716/db4b0e4c2b5541939ae13a56b9f17e32.png
[20161011105922430]: /images/20220716/071ecb95d6a241efa69605ee3e2aa15c.png
[20161011113416291]: /images/20220716/d37e16ccc9bb471c89125606423e1cc5.png
[20161011114617561]: /images/20220716/416e672a8d1342fab31e5e04a34d9c16.png
[20161011114640342]: /images/20220716/6425e56b93824824a5564f751db41681.png
[20161011113456117]: /images/20220716/3f20303e185041cd9c40d21d88438414.png
[20161012103627270]: /images/20220716/3a479d02f471474ebbdb9cc4c7f7accd.png
[20161011113522511]: /images/20220716/d190378c448747ebbdc13cfcc21d34c3.png
[20161011114653715]: /images/20220716/c89c799dda5f4fe3a69b5d2bc84ad3fc.png
[20161011113555309]: /images/20220716/18f52c10bcfc480b9fdc7f61b5e87b8c.png
[20161012103234034]: /images/20220716/6966549a442944bcb534edf93c9b9b81.png
[20161027173942116]: /images/20220716/c6f28c19935342deb97552db4ed9813a.png
[20161027174628056]: /images/20220716/11f59487bbfe43c7a0fd0e140682d19d.png
[20161027175212183]: /images/20220716/17e3d87db11e4da9ad88be83c0f4a3c9.png
[20161027175221387]: /images/20220716/adaec162004e4407b1e6954e43e8fd6e.png
[20161027174800073]: /images/20220716/05c4d099075e4a589fa57e3ede4c7ad4.png
[Mysql_InnoDB]: http://www.2cto.com/database/201508/429967.html