一文彻底搞懂MySQL锁究竟锁的啥2
6. 意向锁
6.1. 背景
前面提到的S锁和X锁的语法规则其实是针对记录的，也就是行锁，原因是InnoDB中行锁用的最多。如果将锁的粒度和锁的基本模式排列组合一下，就会出现如下4种情况：
- 行级
S锁 - 行级
X锁 - 表级
S锁 - 表级
X锁
那么接下来的描述，也就顺理成章了。
如果事务给一个表添加了表级S锁，则：
- 其他事务可以继续获得该表的
S锁，但是无法获取该表的X锁； - 其他事务可以继续获得该表某些行的
S锁，但是无法获取该表某些行的X锁。
如果事务给一个表添加了表级X锁，则：
- 不论是该表的
S锁、X锁，还是该表某些行的S锁、X锁，其他事务都只能干瞪眼儿，啥也获取不了。
挺好理解的吧，总之就是 S锁只能和S锁相容，X锁和其他任何锁都互斥 。问题来了，虽然用的不多，但是万一我真的想给整个表添加一个S锁或者X锁怎么办？
假如我要给表user添加一个S锁，那就必须保证user在表级别上和行级别上都不能有X锁，表级别上还好说一点，无非就是1个内存结构罢了，但是行X锁呢？必须得逐行遍历是否有行X锁吗？
同理，假如我要给表user添加一个X锁，那就必须保证user在表级别上和行级别上都不能有任何锁（S和X都不能有），难不成得逐行遍历是否有S或X锁吗？
遍历是不可能遍历的！这辈子都不可能遍历的！于是， 意向锁 （Intension Lock）诞生了。
6.2. 概念
我们要避免遍历，那最好的办法就是在给行加锁时，先在表级别上添加一个标识。
- 意向共享锁（Intension Shared Lock）：简称
IS锁，当事务试图给行添加S锁时，需要先在表级别上添加一个IS锁； - 意向排他锁（Intension Exclusive Lock）：简称
IX锁，当事务试图给行添加X锁时，需要先在表级别上添加一个IX锁。
这样一来：
- 如果想给
user表添加一个S锁（表级锁），就先看一下user表有没有IX锁；如果有，就说明user表的某些行被加了X锁（行锁），需要等到行的X锁释放，随即IX锁被释放，才可以在user表中添加S锁； - 如果想给
user表添加一个X锁（表级锁），就先看一下user有没有IS锁或IX锁；如果有，就说明user表的某些行被加了S锁或X锁（行锁），需要等到所有行锁被释放，随即IS锁或IX锁被释放，才可以在user表中添加X锁。
需要注意的是，意向锁和意向锁之间是不冲突的，意向锁和行锁之间也不冲突。
只有在对表添加
S锁或X锁时才需要判断当前表是否被添加了IS锁或IX锁，当为表添加IS锁或IX锁时，不需要关心当前表是否已经被添加了其他IS锁或IX锁。
目前为止MySQL锁的基本模式就介绍完了，接下来回到这片文章的题目，MySQL锁，锁住的到底是什么？由于InnoDB的行锁用的最多，这里的锁自然指的是行锁。
7. 行锁的原理
既然都叫行锁了，我们姑且猜测一下，行锁锁住的是一行数据。我们做个实验。
7.1. 没有任何索引的表
我们先创建一张没有任何索引的普通表，语句如下
CREATE TABLE `user_t1` (
`id` int DEFAULT NULL,
`name` varchar(255) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
表中数据如下：
mysql> SELECT * FROM user_t1;
+------+-------------+
| id | name |
+------+-------------+
| 1 | chanmufeng |
| 2 | wanggangdan |
| 3 | wangshangju |
| 4 | zhaotiechui |
+------+-------------+
接下来我们在两个session中开启两个事务。
- 事务1，我们通过
WHERE id = 1“锁住”第1行数据； - 事务2，我们通过
WHERE id = 2"锁住"第2行数据。
一件诡异的事情是，第2个加锁的操作被阻塞了。实际上，T2中不管我们要给user_t1中哪行数据加锁，都会失败！
为什么我SELECT一条数据，却给我锁住了整个表？这个实验直接推翻了我们的猜测， InnoDB的行锁并非直接锁定Record行 。
为什么没有索引的情况下，给某条语句加锁会锁住整个表呢？别急，我们继续。
7.2. 有主键索引的表
我们再创建一个表user_t2，语句如下：
CREATE TABLE `user_t2` (
`id` int NOT NULL,
`name` varchar(255) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4;
和user_t1的不同之处在于为id创建了一个主键索引。表中数据依然如下：
mysql> SELECT * FROM user_t2;
+------+-------------+
| id | name |
+------+-------------+
| 1 | chanmufeng |
| 2 | wanggangdan |
| 3 | wangshangju |
| 4 | zhaotiechui |
+------+-------------+
同样开启两个事务：
- 事务1，通过
WHERE id = 1“锁住”第1行数据； - 事务2
- 依然使用
WHERE id = 1尝试加锁，加锁失败； - 使用
WHERE id = 2尝试加锁，加锁成功。
- 依然使用
既然锁的不是Record行，难不成锁的是id这一列吗？
我们再做最后一个实验。
7.3. 有唯一索引的表
我们再创建一个表user_t3，语句如下：
CREATE TABLE `user_t3` (
`id` int NOT NULL,
`name` varchar(255) DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY (`uk_name`) (`name`)
) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4;
和user_t2的不同之处在于为name列创建了一个唯一索引。表中数据依然如下：
mysql> SELECT * FROM user_t3;
+------+-------------+
| id | name |
+------+-------------+
| 1 | chanmufeng |
| 2 | wanggangdan |
| 3 | wangshangju |
| 4 | zhaotiechui |
+------+-------------+
两个事务：
- 事务1，通过
name字段 “锁住”name为“chanmufeng”的数据； - 事务2
- 依然使用
WHERE name = “chanmufeng”尝试加锁，可以预料，加锁失败； - 使用
WHERE id = 1尝试给同样的行加锁，加锁失败。
- 依然使用
通过3个实验我们发现，行锁锁住的既不是Record行，也不是Column列，那到底锁住的是什么？我们对比一下，上文的3张表的不同点在于索引不同，其实 InnoDB的行锁，就是通过锁住索引来实现的 。
接下来回答3个问题。
8. 三个问题
8.1. 锁住索引？没有索引怎么办？
你说锁住索引？如果我不创建索引，MySQL锁定个啥？
如果我们没有设置主键，InnoDB会优先选取一个不包含NULL值的Unique键作为主键，如果表中连Unique键也没有的话，就会自动为每一条记录添加一个叫做DB_ROW_ID的列作为默认主键，只不过这个主键我们看不到罢了。
下图是数据的行格式。看不懂的话强烈推荐看一下我上面给出的两篇文章，说得非常明白。
行格式
8.2. 为什么第一个实验会锁表？
因为SELECT没有用到索引，会进行全表扫描，然后把DB_ROW_ID作为默认主键的聚簇索引都给锁住了。
8.3. 为什么通过唯一索引给数据加锁，主键索引也会被锁住？
不管是Unique索引还是普通索引，它们的叶子结点中存储的数据都不完整，其中只是存储了作为索引并且排序好的列数据以及对应的主键值。
因此我们通过索引查找数据数据实际上是在索引的B+树中先找到对应的主键，然后根据主键再去主键索引的B+树的叶子结点中找到完整数据，最后返回。所以虽然是两个索引树，但实际上是同一行数据，必须全部锁住。
下面给了一张图，让不了解索引的朋友大致了解一下。上半部分是name列创建的唯一索引的B+树，下半部分是主键索引（也叫聚簇索引）。
假如我们通过WHERE name = '王钢蛋'对数据进行查询，会先用到name列的唯一索引，最终定位到主键值为1，然后再到主键索引中查询id = 1的数据，最终拿到完整的行数据。
这两张图在我索引文章中都有哦～
MySQL锁-索引
9. 总结
至此，我已经回答了文章开头的绝大多数问题。
MySQL锁，是解决资源竞争问题的一种手段。有哪些竞争呢？读—写/写—读，写—写中都会出现资源竞争问题，不同的是前者可以通过MVCC的方式来解决，但是某些情况下你也不得不用锁，因此我也顺便解释了锁和MVCC的关系。
然后介绍了MySQL锁的基本模式，包括共享锁（S锁）和排他锁（X锁），还引入了意向锁。
最后解释了锁到底锁的是什么的问题。通过3个实验，最终解释了InnoDB锁本质上锁的是索引。
-
计算机
+关注
关注
19文章
7520浏览量
88247 -
MySQL
+关注
关注
1文章
817浏览量
26632 -
MVCC
+关注
关注
0文章
13浏览量
1481
发布评论请先 登录
相关推荐
基于MySQL的锁机制
请问DSPflash锁死后，RAM还可以用吗，还是这块芯片就彻底废了？
360为什么会入局智能锁市场
详细介绍MySQL InnoDB存储引擎各种不同类型的锁
工商网监
评论