共计 7069 个字符,预计需要花费 18 分钟才能阅读完成。
锁概念
InnoDB 存储引擎蕴含了三种行锁的算法,别离如下所示:
- Record Lock:行锁,针对的是单行记录;
- Gap Lock:间隙锁,锁定的是一个范畴,然而不蕴含记录自身;
- Next-Key Lock:其实就是行锁 + 间隙锁,蕴含了记录自身和范畴;
为什么须要间隙锁
数据库个别都有四种隔离级别,其中最罕用的就是:已提交读 (Read committed) 和可反复读 (Repeatable read);在已提交读隔离级别下会呈现不可反复读的景象,而在可反复读隔离级别下会呈现幻读(Phantom Read) 的景象;
幻读:同一事务下,间断执行两次同样的 SQL 可能会导致不同的后果;
Innodb 引擎在可反复读隔离级别下并不会呈现幻读的景象,这次要是因为 Innodb 提供了 多版本并发管制 MVCC和 间隙锁 ;常见的 快照读
其实就是应用的 MVCC,而 以后读
就应用了间隙锁;
以下实例有两点阐明:
- Innodb 的可反复读隔离级别下,对以后读应用了间隙锁来解决幻读的问题,所以上面的实例都是基于默认隔离级别 RR;
- Innodb 的锁机制都依赖索引,所以上面的实例围绕索引来开展;
实战
无索引的状况
首先创立一个无索引的表,并初始化数据:
mysql> create table t1(a int);
mysql> insert into t1 values(1),(3),(5);
启动事务 1,执行以后读:
mysql> begin;
mysql> select * from t1 where a=3 for update;
以上事务没有提交,再启动事务 2,以下语句都被阻塞:
mysql> select * from t1 where a=3 for update;
mysql> insert into t1 values(1);
mysql> insert into t1 values(2);
mysql> insert into t1 values(5);
mysql> insert into t1 values(7);
然而这时候去执行快照读还是能够的:
mysql> select * from t1 where a=3;
能够发现在没有索引的状况下,除了快照读什么都干不了,感觉像是表被锁住了,表锁分为读和写锁,在写锁的状况下快照读同样被锁住,而在读锁的状况下能够应用快照读,相似下面无索引的状况;
mysql> lock table t1 read; ## 读锁
mysql> lock table t1 write; ## 写锁
mysql> unlock tables; ## 解锁
那是不是无索引的状况下就应用了表锁那,能够通过如下命令进行查看,首先看一下在表锁的状况下执行插入操作:
mysql> SHOW PROCESSLIST;
+-----+------+-----------------+------+---------+------+------------------------------+--------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+-----+------+-----------------+------+---------+------+------------------------------+--------------------------+
| 75 | ODBC | localhost:65316 | test | Query | 98 | Waiting for table level lock | insert into t1 values(7) |
+-----+------+-----------------+------+---------+------+------------------------------+--------------------------+
能够发现状态一栏显示Waiting for table level lock
,示意以后插入语句在期待表锁;再看一下无索引的状况:
mysql> SHOW PROCESSLIST;
+-----+------+-----------------+------+---------+------+--------+--------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+-----+------+-----------------+------+---------+------+--------+--------------------------+
| 75 | ODBC | localhost:65316 | test | Query | 6 | update | insert into t1 values(7) |
+-----+------+-----------------+------+---------+------+--------+--------------------------+
总结:以上状态并不是在期待表锁,其实 InnoDB 在没有任何索引的状况下,会应用 隐式的主键来进行锁定
。
一般索引的状况
首先创立一个一般索引的表,并初始化数据:
mysql> create table t2 (a int,key(a));
mysql> insert into t2 values(1),(3),(5);
启动事务 1,执行以后读:
mysql> begin;
mysql> select * from t2 where a=3 for update;
启动事务 2,以下语句都被阻塞:
mysql> select * from t2 where a=3 for update;
mysql> insert into t2 values(1);
mysql> insert into t2 values(2);
mysql> insert into t2 values(4);
以下语句不会被阻塞:
mysql> insert into t2 values(5);
mysql> insert into t2 values(7);
mysql> select * from t2 where a=1 for update;
mysql> select * from t2 where a=5 for update;
总结 :能够发现在应用一般索引的状况下,锁定蕴含了行锁和间隙锁,行锁就是a=3
这行,间隙锁蕴含了 (1,3) 和(3,5)
,留神这里两边都是开区间,所以以后读 a=1
和a=5
都能够胜利;然而在插入数据的时候能够发现 a=5
能够插入,然而 a=1
不能插入,这是因为对 Insert
操作会查看插入的 下一条记录是否被锁定
,如果锁定则无奈执行,否则能够执行。
惟一索引的状况
首先创立一个惟一索引的表,并初始化数据:
mysql> create table t3 (a int,unique key(a));
mysql> insert into t3 values (1),(3),(5);
启动事务 1,执行以后读:
mysql> begin;
mysql> select * from t3 where a=3 for update;
启动事务 2,以下语句都被阻塞:
mysql> select * from t3 where a=3 for update;
以下语句不会被阻塞:
mysql> select * from t3 where a=1 for update;
mysql> insert into t3 values(2);
mysql> insert into t3 values(4);
mysql> insert into t3 values(7);
总结 :能够发现当是惟一索引的时候,这时候会 降级为行锁
,只会锁定以后记录,其余插入 SQL 都不会被阻塞;同样主键索引成果也是一样的。
无索引 + 一般索引的状况
首先创立一个领有无索引和一般索引的表,并初始化数据:
mysql> create table t4 (a int,b int,key(a));
mysql> insert into t4 values(1,1),(5,5),(9,9);
因为存在多个字段的状况,所以这时候的加锁状况就和查问的条件无关了:
条件为 a 字段
启动事务 1,执行以后读:
mysql> begin;
mysql> select * from t4 where a=5 for update;
+------+------+
| a | b |
+------+------+
| 5 | 5 |
+------+------+
同时查出了 a = 5 和 b = 5 这条记录,所以会依据无索引和一般索引的状况加锁;启动事务 2,以下语句都被阻塞:
mysql> select * from t4 where a=5 for update;
mysql> insert into t4 values(1,5);
mysql> insert into t4 values(2,5);
mysql> insert into t4 values(8,5);
mysql> select * from t4 where b=1 for update;
mysql> select * from t4 where b=2 for update;
mysql> select * from t4 where b=9 for update;
mysql> select * from t4 where b=11 for update;
以下语句不会被阻塞:
mysql> insert into t4 values(9,5);
mysql> insert into t4 values(10,5);
这里 a 上有一般索引,所以成果和间接应用一般索引相似;然而同时查出来的后果还有 b,因为 b 上是无索引的,所以对于 b 的一系列操作都被阻塞了;
条件为 b 字段
启动事务 1,执行以后读:
mysql> begin;
mysql> select * from t4 where b=5 for update;
+------+------+
| a | b |
+------+------+
| 5 | 5 |
+------+------+
启动事务 2,以下语句都被阻塞:
mysql> insert into t4 values(9,5);
mysql> insert into t4 values(10,5);
mysql> select * from t4 where a=1 for update;
mysql> select * from t4 where a=9 for update;
能够发现条件扭转后,原来 a=5
条件下能够插入的数据,这 b=5
条件下不能插入;并且 a 条件下的两个开区间 1 和 9 也无奈查问了;应该是应用了 隐式的主键来进行锁定
,整个表被锁住了;
条件为 a + b 字段
启动事务 1,执行以后读:
mysql> begin;
mysql> select * from t4 where b=5 and a=5 for update;
+------+------+
| a | b |
+------+------+
| 5 | 5 |
+------+------+
启动事务 2,阻塞的 SQL 同条件为 a 的状况,Mysql 执行打算会优先应用有索引的字段;以下 SQL 都能够执行:
mysql> insert into t4 values(9,5);
mysql> insert into t4 values(10,5);
通过下面的实例,咱们大略能够上面两件事:
- 具体应用哪些锁和咱们应用的查问有很大关系;
- 查出来记录中的多个字段都会启动锁机制,就算查问条件外面没有这个字段;
惟一索引 + 一般索引的状况
首先创立一个领有惟一索引和一般索引的表,并初始化数据:
mysql> create table t5 (a int,b int,unique key(a),key(b));
mysql> insert into t5 values(1,1),(5,5),(9,9);
条件为 a 字段
mysql> begin;
mysql> select * from t5 where a=5 for update;
+------+------+
| a | b |
+------+------+
| 5 | 5 |
+------+------+
这种状况根本和应用惟一索引一样,以下 SQL 都能够执行:
mysql> insert into t5 values(2,2);
mysql> insert into t5 values(10,2);
mysql> select * from t5 where a=1 for update;
阻塞的 SQL 次要蕴含如下:
mysql> select * from t5 where a=5 for update;
mysql> select * from t5 where b=5 for update;
条件为 b 字段
mysql> begin;
mysql> select * from t5 where b=5 for update;
+------+------+
| a | b |
+------+------+
| 5 | 5 |
+------+------+
这种状况根本和应用一般索引一样,以下 SQL 会阻塞:
mysql> insert into t5 values(2,3);
mysql> insert into t5 values(2,7);
mysql> insert into t5 values(2,1);
以下插入 SQL 不会阻塞:
mysql> insert into t5 values(2,9);
条件为 a + b 字段
mysql> begin;
mysql> select * from t5 where b=5 and a=5 for update;
+------+------+
| a | b |
+------+------+
| 5 | 5 |
+------+------+
此种状况根本和应用条件 a 一样,优先应用惟一索引,能够查看执行打算:
mysql> explain select * from t5 where b=5 and a=5 for update;
+----+-------------+-------+-------+---------------+------+---------+-------+------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+-------+---------------+------+---------+-------+------+-------+
| 1 | SIMPLE | t5 | const | a,b | a | 5 | const | 1 | NULL |
+----+-------------+-------+-------+---------------+------+---------+-------+------+-------+
以上实例咱们发现在多索引的状况下,要看执行打算具体应用的什么索引,才会应用什么类型的锁;
组合索引的状况
首先创立领有组合索引的表,并初始化数据:
mysql> create table t6 (a int,b int,key(a,b));
mysql> insert into t6 values(1,1),(5,5),(9,9);
条件为 a 字段
首先开启事务一,执行如下 SQL:
mysql> begin;
mysql> select * from t6 where a=5 for update;
+------+------+
| a | b |
+------+------+
| 5 | 5 |
+------+------+
启动事务 2,以下语句都被阻塞:
mysql> insert into t6 values(1,2);
mysql> insert into t6 values(2,2);
mysql> insert into t6 values(7,2);
mysql> insert into t6 values(9,2);
除了 (9,2) 这条记录其余和应用一般索引没有差异,这里 (9,2) 被阻塞的起因是因为组合索引的存在,导致 (9,9) 记录在 (9,2) 记录的前面,索引会被锁住,同理如果是 (9,10) 是不会被锁住的;
mysql> insert into t6 values(9,10);
mysql> insert into t6 values(10,2);
条件为 b 字段
首先开启事务一,执行如下 SQL:
mysql> begin;
mysql> select * from t6 where b=5 for update;
+------+------+
| a | b |
+------+------+
| 5 | 5 |
+------+------+
启动事务 2,以下语句都被阻塞:
mysql> insert into t6 values(9,2);
mysql> insert into t6 values(9,10);
mysql> insert into t6 values(10,2);
这个其实也好了解,因为应用的是组合索引,会依照最左匹配准则,这时候条件 b = 5 其实是无奈应用索引的,所以这时候和无索引的状况是一样的,以上语句都会被锁住;
条件为 a + b 字段
首先开启事务一,执行如下 SQL:
mysql> begin;
mysql> select * from t6 where b=5 and a=5 for update;
+------+------+
| a | b |
+------+------+
| 5 | 5 |
+------+------+
启动事务 2,阻塞和不阻塞的状况基本一致,执行打算会走组合索引;
总结
通过以上的实例测试大抵做了以下几点总结:
- 无索引的状况会应用隐式的主键来进行锁定,成果就是整个表被锁住了;
- 一般索引的状况下会应用间隙锁,对以后值前后增加开区间的间隙锁,并且对以后值增加行锁;对 Insert 操作会查看插入的下一条记录是否被锁定;
- 惟一索引的状况,间接应用行锁,只对以后行加锁;
- 具体应用哪些锁和咱们应用的查问有很大关系;
- 查出来记录中的多个字段都会启动锁机制,就算查问条件外面没有这个字段;
- 对于查问条件有多个的状况,会依据执行打算抉择索引,而后抉择对应的锁机制。