MySQL中一条SQL的加锁分析
MySQL中一条SQL的加锁分析
SQL1：
select * from t1 where id = 10;（不加锁。因为MySQL是使用多版本并发控制的，读不加锁。）
SQL2:
delete from t1 where id = 10;（需根据多种情况进行分析）
假设t1表上有索引，执行计划一定会选择使用索引进行过滤 (索引扫描)，根据以下组合，来进行分析。
组合一：id列是主键，RC隔离级别
组合四：id列上没有索引，RC隔离级别
组合五：id列是主键，RR隔离级别
组合八：id列上没有索引，RR隔离级别
组合九：Serializable隔离级别
注：在前面八种组合下，也就是RC，RR隔离级别下，SQL1：select操作均不加锁，采用的是快照读，因此在下面的讨论中就忽略了，主要讨论SQL2：delete操作的加锁。
1. id主键 + RC
id是 主键，Read Committed 隔离级别，给定SQL：delete from t1 where id = 10; 只需要将主键上，id = 10的记录加上X锁即可。如下图所示：
结论：id是主键时，此SQL只需要在id=10这条记录上加X锁即可。
示例
#准备数据
mysql> create table t1 (id int,name varchar(10)); mysql> alter table t1 add primary key (id); mysql> insert into t1 values(1,'a'),(4,'c'),(7,'b'),(10,'a'),(20,'d'),(30,'b'); mysql> select * from t1;
+----+------+
| id | name |
+----+------+
| 1 | a |
| 4 | c |
| 7 | b |
| 10 | a |
| 20 | d |
| 30 | b |
+----+------+
6 rows in set (0.00 sec) 会话1 mysql> select @@tx_isolation;
+----------------+
| @@tx_isolation |
+----------------+
| READ-COMMITTED |
+----------------+
1 row in set, 1 warning (0.00 sec) mysql> begin;
Query OK, 0 rows affected (0.00 sec) mysql> delete from t1 where id=10;
Query OK, 1 row affected (0.00 sec) 会话2 mysql> begin;
Query OK, 0 rows affected (0.00 sec) mysql> select * from t1;
+----+------+
| id | name |
+----+------+
| 1 | a |
| 4 | c |
| 7 | b |
| 10 | a |
| 20 | d |
| 30 | b |
+----+------+
6 rows in set (0.00 sec) mysql> update t1 set name='a1' where id=10;
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction mysql> update t1 set name='a1' where id=11;
Query OK, 0 rows affected (0.00 sec)
Rows matched: 0 Changed: 0 Warnings: 0 mysql> update t1 set name='a1' where id=7;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0 从示例中可以看到会话1执行的delete操作，只对id=10加了X锁。
2. id唯一索引 + RC
id不是主键，而是一个Unique的二级索引键值。那么在RC隔离级别下，delete from t1 where id = 10; 需要加什么锁呢？见下图：
此组合中，id是unique索引，而主键是name列。此时，加锁的情况由于组合一有所不同。由于id是unique索引，因此delete语句会选择走id列的索引进行where条件的过滤，在找到id=10的记录后，首先会将unique索引上的id=10索引记录加上X锁，同时，会根据读取到的name列，回主键索引(聚簇索引)，然后将聚簇索引上的name = ‘d’ 对应的主键索引项加X锁。
为什么聚簇索引上的记录也要加锁？试想一下，如果并发的一个SQL，是通过主键索引来更新：update t1 set id = 100 where name = 'd';此时，如果delete语句没有将主键索引上的记录加锁，那么并发的update就会感知不到delete语句的存在，违背了同一记录上的更新/删除需要串行执行的约束。
结论：若id列是unique列，其上有unique索引。那么SQL需要加两个X锁，一个对应于id unique索引上的id = 10的记录，另一把锁对应于聚簇索引上的[name=’d’,id=10]的记录。
示例
准备数据
mysql> create table t1 (id int,name varchar(10));
Query OK, 0 rows affected (0.06 sec) mysql> ALTER TABLE test.t1 ADD UNIQUE INDEX idx_id (id);
Query OK, 0 rows affected (0.07 sec)
Records: 0 Duplicates: 0 Warnings: 0 mysql> ALTER TABLE test.t1 ADD PRIMARY KEY (name);
Query OK, 0 rows affected (0.11 sec)
Records: 0 Duplicates: 0 Warnings: 0 mysql> insert into t1 values(1,'f'),(2,'zz'),(3,'b'),(5,'a'),(6,'c'),(10,'d');
Query OK, 6 rows affected (0.01 sec)
Records: 6 Duplicates: 0 Warnings: 0 会话1 mysql> begin;
Query OK, 0 rows affected (0.01 sec) mysql> delete from t1 where id=10;
Query OK, 1 row affected (0.00 sec) 会话2
mysql> begin;
Query OK, 0 rows affected (0.00 sec) mysql> select * from t1;
+------+------+
| id | name |
+------+------+
| 1 | f |
| 2 | zz |
| 3 | b |
| 5 | a |
| 6 | c |
| 10 | d |
+------+------+
6 rows in set (0.00 sec) mysql> update t1 set id =100 where name='d';
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction mysql> update t1 set id =100 where name='c';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0 mysql> update t1 set id =101 where name='a';
Query OK, 1 row affected (0.01 sec)
Rows matched: 1 Changed: 1 Warnings: 0
3. id非唯一索引 + RC
id列是一个普通索引。假设delete from t1 where id = 10; 语句，仍旧选择id列上的索引进行过滤where条件，那么此时会持有哪些锁？同样见下图：
根据此图，可以看到，首先，id列索引上，满足id = 10查询条件的记录，均已加锁。同时，这些记录对应的主键索引上的记录也都加上了锁。与组合二唯一的区别在于，组合二最多只有一个满足等值查询的记录，而组合三会将所有满足查询条件的记录都加锁。
结论：若id列上有非唯一索引，那么对应的所有满足SQL查询条件的记录，都会被加锁。同时，这些记录在主键索引上的记录，也会被加锁。
示例
准备数据
mysql> create table t1 (id int,name varchar(10)); mysql> ALTER TABLE test.t1 ADD PRIMARY KEY (name); mysql> alter table t1 add index idx_id (id); mysql> insert into t1 values(2,'zz'),(6,'c'),(10,'b'),(10,'d'),(11,'f'),(15,'a'); 会话1 mysql> begin;
Query OK, 0 rows affected (0.00 sec) mysql> delete from t1 where id=10;
Query OK, 2 rows affected (0.00 sec) 会话2 mysql> select * from t1;
+------+------+
| id | name |
+------+------+
| 2 | zz |
| 6 | c |
| 10 | b |
| 10 | d |
| 11 | f |
| 15 | a |
+------+------+
6 rows in set (0.00 sec) mysql> begin;
Query OK, 0 rows affected (0.00 sec) mysql> update t1 set id=11 where name='b';
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction mysql> update t1 set id=11 where name='d';
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction mysql> update t1 set id=11 where name='f';
Query OK, 0 rows affected (0.00 sec)
Rows matched: 1 Changed: 0 Warnings: 0 mysql> update t1 set id=11 where name='c';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
4. id无索引 + RC
id列上没有索引，where id = 10;这个过滤条件，没法通过索引进行过滤，那么只能走全表扫描做过滤。
对应于这个组合，SQL会加什么锁？或者是换句话说，全表扫描时，会加什么锁？这个答案也有很多：有人说会在表上加X锁；有人说会将聚簇索引上，选择出来的id = 10;的记录加上X锁。那么实际情况呢？请看下图：
由于id列上没有索引，因此只能走聚簇索引，进行全部扫描。从图中可以看到，满足删除条件的记录有两条，但是，聚簇索引上所有的记录，都被加上了X锁。无论记录是否满足条件，全部被加上X锁。既不是加表锁，也不是在满足条件的记录上加行锁。
为什么不是只在满足条件的记录上加锁呢？这是由于MySQL的实现决定的。如果一个条件无法通过索引快速过滤，那么存储引擎层面就会将所有记录加锁后返回，然后由MySQL Server层进行过滤。因此也就把所有的记录，都锁上了。
注：在实际的实现中，MySQL有一些改进，在MySQL Server过滤条件，发现不满足后，会调用unlock_row方法，把不满足条件的记录放锁 (违背了2PL的约束)。这样做，保证了最后只会持有满足条件记录上的锁，但是每条记录的加锁操作还是不能省略的。
结论：若id列上没有索引，SQL会走聚簇索引的全扫描进行过滤，由于过滤是由MySQL Server层面进行的。因此每条记录，无论是否满足条件，都会被加上X锁。但是，为了效率考量，MySQL做了优化，对于不满足条件的记录，会在判断后放锁，最终持有的，是满足条件的记录上的锁，但是不满足条件的记录上的加锁/放锁动作不会省略。同时，优化也违背了2PL的约束。
示例
准备数据
mysql> create table t1 (id int,name varchar(10)); mysql> ALTER TABLE test.t1 ADD PRIMARY KEY (name); mysql> insert into t1 values(5,'a'),(3,'b'),(10,'d'),(2,'f'),(10,'g'),(9,'zz'); 会话1
mysql> begin;
Query OK, 0 rows affected (0.00 sec) mysql> delete from t1 where id=10;
Query OK, 2 rows affected (0.00 sec) 会话2
mysql> select * from t1;
+------+------+
| id | name |
+------+------+
| 5 | a |
| 3 | b |
| 10 | d |
| 2 | f |
| 10 | g |
| 9 | zz |
+------+------+
6 rows in set (0.00 sec) mysql> begin;
Query OK, 0 rows affected (0.00 sec) mysql> update t1 set id=6 where name='a';
Query OK, 1 row affected (0.01 sec)
Rows matched: 1 Changed: 1 Warnings: 0 mysql> update t1 set id=6 where name='b';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0 mysql> update t1 set id=6 where name='d';
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
mysql> update t1 set id=6 where name='f';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0 mysql> update t1 set id=6 where name='g';
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction mysql> update t1 set id=6 where name='zz';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0 mysql> update t1 set id=6 where name='zzf';
Query OK, 0 rows affected (0.00 sec)
Rows matched: 0 Changed: 0 Warnings: 0 实验结果与推倒的结论不一致， 实验结果看出只锁住了id=10的两行。
5. id主键 + RR
id列是主键列，Repeatable Read隔离级别，针对delete from t1 where id = 10; 这条SQL，加锁与组合一："id主键 + RC"一致。
示例：
mysql> create table t1 (id int,name varchar(10)); mysql> alter table t1 add primary key (id); mysql> insert into t1 values(1,'a'),(4,'c'),(7,'b'),(10,'a'),(20,'d'),(30,'b'); mysql> select * from t1;
+----+------+
| id | name |
+----+------+
| 1 | a |
| 4 | c |
| 7 | b |
| 10 | a |
| 20 | d |
| 30 | b |
+----+------+
6 rows in set (0.00 sec) mysql> select @@tx_isolation;
+-----------------+
| @@tx_isolation |
+-----------------+
| REPEATABLE-READ |
+-----------------+
1 row in set, 1 warning (0.00 sec) 会话1 mysql> begin;
Query OK, 0 rows affected (0.01 sec) mysql> delete from t1 where id=10;
Query OK, 1 row affected (0.00 sec) 会话2 mysql> select * from t1;
+----+------+
| id | name |
+----+------+
| 1 | a |
| 4 | c |
| 7 | b |
| 10 | a |
| 20 | d |
| 30 | b |
+----+------+
6 rows in set (0.00 sec) mysql> update t1 set name='a1' where id=10;
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction mysql> update t1 set name='a1' where id=11;
Query OK, 0 rows affected (0.00 sec)
Rows matched: 0 Changed: 0 Warnings: 0 mysql> update t1 set name='a1' where id=7;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
6. id唯一索引 + RR
id唯一索引 + RR的加锁与id唯一索引，RC一致。两个X锁，id唯一索引满足条件的记录上一个，对应的聚簇索引上的记录一个。
示例：
准备数据
mysql> create table t1 (id int,name varchar(10)); mysql> ALTER TABLE test.t1 ADD UNIQUE INDEX idx_id (id); mysql> ALTER TABLE test.t1 ADD PRIMARY KEY (name); mysql> insert into t1 values(1,'f'),(2,'zz'),(3,'b'),(5,'a'),(6,'c'),(10,'d'); 会话1 mysql> begin;
Query OK, 0 rows affected (0.00 sec) mysql> delete from t1 where id=10;
Query OK, 1 row affected (0.01 sec) 会话2 mysql> begin;
Query OK, 0 rows affected (0.00 sec) mysql> select * from t1;
+------+------+
| id | name |
+------+------+
| 1 | f |
| 2 | zz |
| 3 | b |
| 5 | a |
| 6 | c |
| 10 | d |
+------+------+
6 rows in set (0.00 sec) mysql> update t1 set id =100 where name='d';
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction mysql> update t1 set id =100 where name='c';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0 mysql> update t1 set id =101 where name='a';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
7. id非唯一索引 + RR
在Repeatable Read隔离级别，id上有一个非唯一索引，执行delete from t1 where id = 10; 假设选择id列上的索引进行条件过滤，最后的加锁行为，是怎么样的呢？同样看下面这幅图：
此图，相对于组合三：[id列上非唯一锁，Read Committed]看似相同，其实却有很大的区别。最大的区别在于，这幅图中多了一个GAP锁，而且GAP锁看起来也不是加在记录上的，倒像是加载两条记录之间的位置，GAP锁有何用？
其实这个多出来的GAP锁，就是RR隔离级别，相对于RC隔离级别，不会出现幻读的关键。确实，GAP锁锁住的位置，也不是记录本身，而是两条记录之间的GAP。所谓幻读，就是同一个事务，连续做两次当前读 (例如：select * from t1 where id = 10 for update;)，那么这两次当前读返回的是完全相同的记录 (记录数量一致，记录本身也一致)，第二次的当前读，不会比第一次返回更多的记录 (幻象)。
如何保证两次当前读返回一致的记录，那就需要在第一次当前读与第二次当前读之间，其他的事务不会插入新的满足条件的记录并提交。为了实现这个功能，GAP锁应运而生。
如图中所示，有哪些位置可以插入新的满足条件的项 (id = 10)，考虑到B+树索引的有序性，满足条件的项一定是连续存放的。记录[6,c]之前，不会插入id=10的记录；[6,c]与[10,b]间可以插入[10, aa]；[10,b]与[10,d]间，可以插入新的[10,bb],[10,c]等；[10,d]与[11,f]间可以插入满足条件的[10,e],[10,z]等；而[11,f]之后也不会插入满足条件的记录。因此，为了保证[6,c]与[10,b]间，[10,b]与[10,d]间，[10,d]与[11,f]不会插入新的满足条件的记录，MySQL选择了用GAP锁，将这三个GAP给锁起来。
Insert操作，如insert [10,aa]，首先会定位到[6,c]与[10,b]间，然后在插入前，会检查这个GAP是否已经被锁上，如果被锁上，则Insert不能插入记录。因此，通过第一遍的当前读，不仅将满足条件的记录锁上 (X锁)，与组合三类似。同时还是增加3把GAP锁，将可能插入满足条件记录的3个GAP给锁上，保证后续的Insert不能插入新的id=10的记录，也就杜绝了同一事务的第二次当前读，出现幻象的情况。
既然防止幻读，需要靠GAP锁的保护，为什么组合五、组合六，也是RR隔离级别，却不需要加GAP锁呢？
GAP锁的目的，是为了防止同一事务的两次当前读，出现幻读的情况。而组合五，id是主键；组合六，id是unique键，都能够保证唯一性。一个等值查询，最多只能返回一条记录，而且新的相同取值的记录，一定不会在新插入进来，因此也就避免了GAP锁的使用。
其实，针对此问题，还有一个更深入的问题：如果组合五、组合六下，针对SQL：select * from t1 where id = 10 for update; 第一次查询，没有找到满足查询条件的记录，那么GAP锁是否还能够省略？
结论：Repeatable Read隔离级别下，id列上有一个非唯一索引，对应SQL：delete from t1 where id = 10; 首先，通过id索引定位到第一条满足查询条件的记录，加记录上的X锁，加GAP上的GAP锁，然后加主键聚簇索引上的记录X锁，然后返回；然后读取下一条，重复进行。直至进行到第一条不满足条件的记录[11,f]，此时，不需要加记录X锁，但是仍旧需要加GAP锁，最后返回结束。
示例
准备数据
mysql> create table t1 (id int,name varchar(10)); mysql> ALTER TABLE test.t1 ADD PRIMARY KEY (name); mysql> alter table t1 add index idx_id (id); mysql> insert into t1 values(2,'zz'),(6,'c'),(10,'b'),(10,'d'),(11,'f'),(15,'a'); 会话1 mysql> begin;
Query OK, 0 rows affected (0.00 sec) mysql> delete from t1 where id=10;
Query OK, 2 rows affected (0.00 sec) 会话2 mysql> select * from t1;
+------+------+
| id | name |
+------+------+
| 2 | zz |
| 6 | c |
| 10 | b |
| 10 | d |
| 11 | f |
| 15 | a |
+------+------+
6 rows in set (0.00 sec) mysql> begin;
Query OK, 0 rows affected (0.00 sec) mysql> insert into t1 values(6,'aa');
Query OK, 1 row affected (0.00 sec)
mysql> insert into t1 values(6,'bb');
Query OK, 1 row affected (0.01 sec) mysql> insert into t1 values(6,'cc');
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
mysql> insert into t1 values(7,'cc');
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
mysql> insert into t1 values(8,'cc');
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
mysql> insert into t1 values(9,'cc');
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
mysql> insert into t1 values(10,'cc');
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
mysql> insert into t1 values(11,'cc');
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction mysql> insert into t1 values(11,'ff');
Query OK, 1 row affected (0.00 sec)
mysql> insert into t1 values(11,'g');
Query OK, 1 row affected (0.00 sec)
8. id无索引 + RR
Repeatable Read隔离级别下，id列上没有索引。此时SQL：delete from t1 where id = 10; 只能进行全表扫描。最终的加锁情况，如下图所示：
如图，这是一个很恐怖的现象。首先，聚簇索引上的所有记录，都被加上了X锁。其次，聚簇索引每条记录间的间隙(GAP)，也同时被加上了GAP锁。这个示例表，只有6条记录，一共需要6个记录锁，7个GAP锁。试想，如果表上有1000万条记录呢？
在这种情况下，这个表上，除了不加锁的快照度，其他任何加锁的并发SQL，均不能执行，不能更新，不能删除，不能插入，全表被锁死。
当然，跟id无索引, Read Committed类似，这个情况下，MySQL也做了一些优化，就是所谓的semi-consistent read。
semi-consistent read开启的情况下，对于不满足查询条件的记录，MySQL会提前放锁。
针对上面的这个用例，就是除了记录[d,10]，[g,10]之外，所有的记录锁都会被释放，同时不加GAP锁。
semi-consistent read如何触发：1)read committed隔离级别；2)Repeatable Read隔离级别，同时设置了 innodb_locks_unsafe_for_binlog 参数。
更详细的关于semi-consistent read的介绍，可参考博客：MySQL+InnoDB semi-consitent read原理及实现分析 。
结论：在Repeatable Read隔离级别下，如果进行全表扫描的当前读，那么会锁上表中的所有记录，同时会锁上聚簇索引内的所有GAP，杜绝所有的并发 更新/删除/插入 操作。当然，也可以通过触发semi-consistent read，来缓解加锁开销与并发影响，但是semi-consistent read本身也会带来其他问题，不建议使用。
示例
准备数据
mysql> create table t1 (id int,name varchar(10)); mysql> ALTER TABLE test.t1 ADD PRIMARY KEY (name); mysql> insert into t1 values(5,'a'),(3,'b'),(10,'d'),(2,'f'),(10,'g'),(9,'zz'); 会话1
mysql> begin;
Query OK, 0 rows affected (0.00 sec) mysql> delete from t1 where id=10;
Query OK, 2 rows affected (0.00 sec) 会话2
mysql> begin;
Query OK, 0 rows affected (0.00 sec) mysql> select * from t1;
+------+------+
| id | name |
+------+------+
| 5 | a |
| 3 | b |
| 10 | d |
| 2 | f |
| 10 | g |
| 9 | zz |
+------+------+
6 rows in set (0.00 sec) mysql> insert into t1 values(1,'j');
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
mysql> insert into t1 values(2,'j');
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
mysql> insert into t1 values(100,'j');
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
9. Serializable
Serializable隔离级别。对于SQL2：delete from t1 where id = 10; 来说，Serializable隔离级别与Repeatable Read隔离级别完全一致，因此不做介绍。
Serializable隔离级别，影响的是SQL1：select * from t1 where id = 10; 这条SQL，在RC，RR隔离级别下，都是快照读，不加锁。但是在Serializable隔离级别，SQL1会加读锁，也就是说快照读不复存在，MVCC并发控制降级为Lock-Based CC。
结论：在MySQL/InnoDB中，所谓的读不加锁，并不适用于所有的情况，而是隔离级别相关的。Serializable隔离级别，读不加锁就不再成立，所有的读操作，都是当前读。
10. 一条复杂的SQL
再来看一个稍微复杂点的SQL，用于说明MySQL加锁的另外一个逻辑。SQL用例如下：
如图中的SQL，会加什么锁？假定在Repeatable Read隔离级别下 ，同时，假设SQL走的是idx_t1_pu索引。
在详细分析这条SQL的加锁情况前，还需要有一个知识储备，那就是一个SQL中的where条件如何拆分？具体的介绍，建议阅读文章：SQL中的where条件，在数据库中提取与应用浅析 。分析结果：
Index key：pubtime > 1 and puptime < 20。此条件，用于确定SQL在idx_t1_pu索引上的查询范围。
Index Filter：userid = 'hdc' 。此条件，可以在idx_t1_pu索引上进行过滤，但不属于Index Key。
Table Filter：comment is not NULL。此条件，在idx_t1_pu索引上无法过滤，只能在聚簇索引上过滤。
在分析出SQL where条件的构成之后，再来看看这条SQL的加锁情况 (RR隔离级别)，如下图所示：
从图中可以看出，在Repeatable Read隔离级别下，由Index Key所确定的范围，被加上了GAP锁；Index Filter锁给定的条件 (userid = ‘hdc’)何时过滤，视MySQL的版本而定，在MySQL 5.6版本之前，不支持Index Condition Pushdown(ICP)，因此Index Filter在MySQL Server层过滤，在5.6后支持了Index Condition Pushdown，则在index上过滤。若不支持ICP，不满足Index Filter的记录，也需要加上记录X锁，若支持ICP，则不满足Index Filter的记录，无需加记录X锁 (图中，用红色箭头标出的X锁，是否要加，视是否支持ICP而定)；而Table Filter对应的过滤条件，则在聚簇索引中读取后，在MySQL Server层面过滤，因此聚簇索引上也需要X锁。最后，选取出了一条满足条件的记录[8,hdc,d,5,good]，但是加锁的数量，要远远大于满足条件的记录数量。
结论：在Repeatable Read隔离级别下，针对一个复杂的SQL，首先需要提取其where条件。Index Key确定的范围，需要加上GAP锁；Index Filter过滤条件，视MySQL版本是否支持ICP，若支持ICP，则不满足Index Filter的记录，不加X锁，否则需要X锁；Table Filter过滤条件，无论是否满足，都需要加X锁。
示例：
准备数据
mysql> create table t1(id int,userid varchar(10),blogid varchar(10),pubtime int,comment varchar(10));
mysql> alter table t1 add index idx_t1_pu (pubtime,userid);
mysql> alter table t1 add primary key (id); mysql> insert into t1 values(1,'hdc','a',10,null),(4,'yyy','b',3,null),(6,'hdc','c',100,null),(8,'hdc','d',5,'good'),(10,'hdc','e',1,null),(100,'bbb','f',20,null); mysql> select * from t1;
+-----+--------+--------+---------+---------+
| id | userid | blogid | pubtime | comment |
+-----+--------+--------+---------+---------+
| 1 | hdc | a | 10 | NULL |
| 4 | yyy | b | 3 | NULL |
| 6 | hdc | c | 100 | NULL |
| 8 | hdc | d | 5 | good |
| 10 | hdc | e | 1 | NULL |
| 100 | bbb | f | 20 | NULL |
+-----+--------+--------+---------+---------+
6 rows in set (0.00 sec) 会话1 mysql> begin;
Query OK, 0 rows affected (0.00 sec) mysql> select * from t1 force index (idx_t1_pu) where pubtime > 1 and pubtime < 20 and userid = 'hdc' and comment is not null for update;
+----+--------+--------+---------+---------+
| id | userid | blogid | pubtime | comment |
+----+--------+--------+---------+---------+
| 8 | hdc | d | 5 | good |
+----+--------+--------+---------+---------+
1 row in set (0.00 sec) 会话2
mysql> delete from t1 where pubtime > 1 and pubtime < 20 and userid = 'hdc' and comment is not null;
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction mysql> delete from t1 where pubtime=1;
Query OK, 1 row affected (0.01 sec) mysql> delete from t1 where pubtime=3;
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction mysql> delete from t1 where pubtime=5;
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction mysql> delete from t1 where pubtime=10;
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction mysql> delete from t1 where pubtime=20;
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction mysql> delete from t1 where pubtime=100;
Query OK, 1 row affected (0.00 sec)
11. 死锁原理与分析
下面，来看看两个死锁的例子
两个Session的两条SQL产生死锁
每个事务执行两条SQL，分别持有了一把锁，然后加另一把锁，产生死锁。
示例
create table t1 (id int,name varchar(10));
alter table t1 add primary key (id);
alter table t1 add index idx_name (name);
insert into t1 values(1,'aaa'),(2,'ccc'),(3,'aaa'),(4,'bbb'),(5,'ccc'),(6,'zzz'); 会话1 mysql> begin;
Query OK, 0 rows affected (0.01 sec) mysql> select * from t1 where id=1 for update;
+----+------+
| id | name |
+----+------+
| 1 | aaa |
+----+------+
1 row in set (0.00 sec) mysql> update t1 set name='qqq' where id=5;
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction 会话2
mysql> begin;
Query OK, 0 rows affected (0.00 sec) mysql> delete from t1 where id=5;
Query OK, 1 row affected (0.00 sec) mysql> delete from t1 where id=1;
Query OK, 1 row affected (0.03 sec) error日志 2018-09-07T08:55:27.931528Z 17 [Note] InnoDB: *** WE ROLL BACK TRANSACTION (1) 2018-09-07T08:59:43.321054Z 17 [Note] InnoDB: Transactions deadlock detected, dumping detailed information.
2018-09-07T08:59:43.321129Z 17 [Note] InnoDB:
*** (1) TRANSACTION: TRANSACTION 448141, ACTIVE 32 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 16, OS thread handle 139708911650560, query id 238 localhost root updating
update t1 set name='qqq' where id=5
2018-09-07T08:59:43.321178Z 17 [Note] InnoDB: *** (1) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 574 page no 3 n bits 80 index PRIMARY of table `test`.`t1` trx id 448141 lock_mode X locks rec but not gap waiting
Record lock, heap no 6 PHYSICAL RECORD: n_fields 4; compact format; info bits 32
0: len 4; hex 80000005; asc ;;
1: len 6; hex 00000006d68e; asc ;;
2: len 7; hex 300000000606cd; asc 0 ;;
3: len 3; hex 636363; asc ccc;; 2018-09-07T08:59:43.321659Z 17 [Note] InnoDB: *** (2) TRANSACTION: TRANSACTION 448142, ACTIVE 17 sec starting index read
mysql tables in use 1, locked 1
3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1
MySQL thread id 17, OS thread handle 139708912715520, query id 239 localhost root updating
delete from t1 where id=1
2018-09-07T08:59:43.321700Z 17 [Note] InnoDB: *** (2) HOLDS THE LOCK(S): RECORD LOCKS space id 574 page no 3 n bits 80 index PRIMARY of table `test`.`t1` trx id 448142 lock_mode X locks rec but not gap
Record lock, heap no 6 PHYSICAL RECORD: n_fields 4; compact format; info bits 32
0: len 4; hex 80000005; asc ;;
1: len 6; hex 00000006d68e; asc ;;
2: len 7; hex 300000000606cd; asc 0 ;;
3: len 3; hex 636363; asc ccc;; 2018-09-07T08:59:43.322123Z 17 [Note] InnoDB: *** (2) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 574 page no 3 n bits 80 index PRIMARY of table `test`.`t1` trx id 448142 lock_mode X locks rec but not gap waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 4; hex 80000001; asc ;;
1: len 6; hex 00000006d663; asc c;;
2: len 7; hex f4000000060110; asc ;;
3: len 3; hex 616161; asc aaa;; 2018-09-07T08:59:43.347673Z 17 [Note] InnoDB: *** WE ROLL BACK TRANSACTION (1)
两个Session的一条SQL，产生死锁
虽然每个Session都只有一条语句，仍旧会产生死锁。要分析这个死锁，首先必须用到本文前面提到的MySQL加锁的规则。针对Session 1，从name索引出发，读到的[hdc, 1]，[hdc, 6]均满足条件，不仅会加name索引上的记录X锁，而且会加聚簇索引上的记录X锁，加锁顺序为先[1,hdc,100]，后[6,hdc,10]。而Session 2，从pubtime索引出发，[10,6],[100,1]均满足过滤条件，同样也会加聚簇索引上的记录X锁，加锁顺序为[6,hdc,10]，后[1,hdc,100]。发现没有，跟Session 1的加锁顺序正好相反，如果两个Session恰好都持有了第一把锁，请求加第二把锁，死锁就发生了。
结论：死锁的发生与否，并不在于事务中有多少条SQL语句，死锁的关键在于：两个(或以上)的Session加锁的顺序不一致。而使用本文上面提到的，分析MySQL每条SQL语句的加锁规则，分析出每条语句的加锁顺序，然后检查多个并发SQL间是否存在以相反的顺序加锁的情况，就可以分析出各种潜在的死锁情况，也可以分析出线上死锁发生的原因。
MySQL中一条SQL的加锁分析的更多相关文章
- MySQL innodb中各种SQL语句加锁分析
概要 Locking read( SELECT ... FOR UPDATE or SELECT ... LOCK IN SHARE MODE),UPDATE以及DELETE语句通常会在他扫描的索引所 ...
- 数据库：Mysql中“select ... for update”排他锁分析
Mysql InnoDB 排他锁 用法: select … for update; 例如:select * from goods where id = 1 for update; 排他锁的申请前提:没 ...
- SQL语句加锁分析
背景 MySQL中SQL加锁的情况十分复杂,不同隔离级别.不同索引类型.索引是否命中的SQL加锁各不相同. 然而在分析死锁过程当中,熟知各种情况的SQL加锁是分析死锁的关键,因此需要将MySQL的各种 ...
- 向mysql中批量插入数据的性能分析
MYSQL批量插入数据库实现语句性能分析 假定我们的表结构如下 代码如下 CREATE TABLE example (example_id INT NOT NULL,name VARCHAR( 5 ...
- MySQL：一条SQL是如何执行的
目录 MySQL基本架构 Server层 连接器 查询缓存 分析器 优化器 执行器 存储引擎层 InnoDB MyISAM Memory SQL执行流程 MySQL基本架构 在讲SQL语句是如何执行之 ...
- MySQL中的基本SQL语句
标准SQL包含了4种基本的语句类别: DDL语句,数据定义语句,主要用来定义数据库,表名,字段,例如create,drop,alter. DML语句,数据操作语句,用来对数据记录的增删改查,还用来保证 ...
- mysql 中常用的 sql 语句
SQL分类: DDL-----数据定义语言(CREATE--创建,ALTER--修改. DROP--删除表,DECLARE--声明) DML-----数据定义语言(SELECT--查询,DELECT- ...
- 【MySQL】10条SQL优化语句，让你的MySQL数据库跑得更快！
慢SQL消耗了70%~90%的数据库CPU资源: SQL语句独立于程序设计逻辑,相对于对程序源代码的优化,对SQL语句的优化在时间成本和风险上的代价都很低: SQL语句可以有不同的写法: 1 不使用子 ...
- mysql中导入导出sql文件
1.导出整个数据库: mysqldump -u用户名 -p密码 数据库名 > 导出的文件名 例:mysqldump -uroot -proot user > user.sql 2.导出一个 ...
随机推荐
- Webservice入门简单实例
转载大神 项目目的: 程序A调用程序B中的方法C.. https://blog.csdn.net/lovebosom/article/details/51558139 ...
- mirror与repository的关系
mirror与repository的关系 mirror管理的两个repository的关系,本来是访问repoA, 但是repoB mirrorOf repoA, 就会去repoB上去找. https ...
- java中存储金额
很早之前, 记得一次面试, 面试官问存储金钱用什么数据类型? 当时只知道8种数据类型(boolean, byte, short, int, long, float, double, char)的我, ...
- linux网卡软中断shell脚本
LANG=C;export LANG; service irqbalance stop >/dev/null 2>&1;chkconfig irqbalance off; bon ...
- asp.net 多语言 在IIS7.5发布出现找不到资源文件
我也遇到这个问题,纠结了半天, 最后把资源文件的属性改为:内容 就可以了. 见:http://q.cnblogs.com/q/60443/
- NodeJS学习视频
腾讯课堂初级课程 https://ke.qq.com/webcourse/index.html#course_id=196698&term_id=100233129&taid=1064 ...
- log4j.properties配置详情
log4j: log for java 是Apache的一个开源项目! 00.将我们的日志信息,输出到指定的位置(控制台 文件中) 01.我们可以控制每一条日志的输出格式 02.我们设置日志信息的 ...
- dubbo服务降级(2)
dubbo降级服务 使用dubbo在进行服务调用时,可能由于各种原因(服务器宕机/网络超时/并发数太高等),调用中就会出现RpcException,调用失败. 服务降级就是指在由于非业务异常导致的服务 ...
- copyout函数
copyout Kernel Service Purpose Copies data between user and kernel memory. Syntax #include <sys ...
- 大家一起和snailren学java-(一)对象导论
OOP,是java语言的特性.面向对象思想贯穿整个java开发. 那什么是面向对象呢?什么是对象? 在面向对象设计语言看来,万事万物都为对象.生活中的一个物体,有自己的属性,有自己的活动.比如一辆汽车 ...