《面试必会系列之MySQL锁》由会员分享，可在线阅读，更多相关《面试必会系列之MySQL锁（10页珍藏版）》请在金锄头文库上搜索。
1、面试必会系列之MySQL锁相关内容序言：文章内容适用于每一个学习后端编程的朋友详细总结了一下MySQL锁相关的知识，分享给大家MySQL的锁概述数据库锁定机制简单来说，就是数据库为了保证数据的一致性，而使各种共享资源在被并发访问变得有序所设计的一种规则。对于任何一种数据库来说都需要有相应的锁定机制，所以MySQL自然也不能例外。MySQL数据库由于其自身架构的特点，存在多种数据存储引擎，每种存储引擎所针对的应用场景特点都不太一样，为了满足各自特定应用场景的需求，每种存储引擎的锁定机制都是为各自所面对的特定场景而优化设计，所以各存储引擎的锁定机制也有较大区别。本文没有说明的情况下默认使用的是In
2、nodb引擎。Innodb原理(简单说一下 innodb一定存在聚簇索引，默认以主键作为聚簇索引 有几个索引，就有几棵B+树(不考虑hash索引的情形) 聚簇索引的叶子节点为磁盘上的真实数据。非聚簇索引的叶子节点还是索引，指向聚簇索引B+树。 锁的分类 共享锁(S锁): 假设事务T1对数据A加上共享锁，那么事务T2可以读数据A，不能修改数据A。 排他锁(X锁): 假设事务T1对数据A加上排他锁，那么事务T2不能读数据A，不能修改数据A。我们通过update、delete等语句加上的锁都是行级别的锁。只有LOCK TABLE READ和LOCK TABLE WRITE才能申请表级别的锁。 意向共
3、享锁(IS锁): 一个事务在获取（任何一行/或者全表）S锁之前，一定会先在所在的表上加IS锁。 意向排他锁(IX锁): 一个事务在获取（任何一行/或者全表）X锁之前，一定会先在所在的表上加IX锁。 意向锁存在的目的这里说一下意向锁存在的目的。假设事务T1，用X锁来锁住了表上的几条记录，那么此时表上存在IX锁，即意向排他锁。那么此时事务T2要进行LOCK TABLE WRITE的表级别锁的请求，可以直接根据意向锁是否存在而判断是否有锁冲突。加锁算法 Record Locks： 简单翻译为行锁。注意了，该锁是对索引记录进行加锁！锁是加在索引上而不是行上的。注意了，innodb一定存在聚簇索引，因此
4、行锁最终都会落到聚簇索引上！ Gap Locks： 简单翻译为间隙锁，是对索引的间隙加锁，其目的只有一个，防止其他事物插入数据。在Read Committed隔离级别下，不会使用间隙锁。这里我对官网补充一下，隔离级别比Read Committed低的情况下，也不会使用间隙锁，如隔离级别为Read Uncommited时，也不存在间隙锁。当隔离级别为Repeatable Read和Serializable时，就会存在间隙锁。 Next-Key Locks： 这个理解为Record Lock+索引前面的Gap Lock。记住了，锁住的是索引前面的间隙！比如一个索引包含值，10，11，13和20。那
5、么，间隙锁的范围如下12345(negative infinity, 10(10, 11(11, 13(13, 20(20, positive infinity)还有不懂的地方可以看一下MySQL的官方文档快照读和当前读在mysql中select分为快照读和当前读，执行下面的语句select * from table where id = ?;执行的是快照读，读的是数据库记录的快照版本，是不加锁的。（这种说法在隔离级别为Serializable中不成立，后面会再补充。）那么，执行select * from table where id = ? lock in share mode;会对读取记录
6、加S锁 (共享锁)，执行select * from table where id = ? for update会对读取记录加X锁 (排他锁)，那么加的是表锁还是行锁呢？表锁or行锁 针对这点，我们先回忆一下事务的四个隔离级别，他们由弱到强如下所示: Read Uncommited(RU)： 读未提交，一个事务可以读到另一个事务未提交的数据！ Read Committed (RC)： 读已提交，一个事务可以读到另一个事务已提交的数据! Repeatable Read (RR): 可重复读，加入间隙锁，一定程度上避免了幻读的产生！注意了，只是一定程度上，并没有完全避免!另外就是记住从该级别才开始加
7、入间隙锁(这句话记下来，后面有用到)! Serializable： 串行化，该级别下读写串行化，且所有的select语句后都自动加上lock in share mode，即使用了共享锁。因此在该隔离级别下，使用的是当前读，而不是快照读。 那么关于是表锁还是行锁，大家可以看到网上最流传的一个说法是这样的InnoDB行锁是通过给索引上的索引项加锁来实现的，这一点MySQL与Oracle不同，后者是通过在数据块中对相应数据行加锁来实现的。 InnoDB这种行锁实现特点意味着：只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁！这句话大家可以搜一下，都是你抄我的，我抄你的
8、。那么，这句话本身有两处错误！错误一: 并不是用表锁来实现锁表的操作，而是利用了Next-Key Locks，也可以理解为是用了行锁+间隙锁来实现锁表的操作!为了便于说明，我来个例子，假设有表数据如下，pId为主键索引pId(int)name(varchar)num(int)1aaa1002bbb2007ccc200执行语句(name列无索引)select * from table where name = aaa for update那么此时在pId=1,2,7这三条记录上存在行锁(把行锁住了)。另外，在(-,1)(1,2)(2,7)(7,+)上存在间隙锁(把间隙锁住了)。因此，给人一种整个
9、表锁住的错觉！ps: 对该结论有疑问的，可自行执行show engine innodb status;语句进行分析。错误二: 所有文章都不提隔离级别！注意上面说的，之所以能够锁表，是通过行锁+间隙锁来实现的。那么，RU和RC都不存在间隙锁，这种说法在RU和RC中还能成立么？因此，该说法只在RR和Serializable中是成立的。如果隔离级别为RU和RC，无论条件列上是否有索引，都不会锁表，只锁行！分析 下面来对开始的问题作出解答，假设有表如下，pId为主键索引pId(int)name(varchar)num(int)1aaa1002bbb2003bbb3007ccc200RC/RU+条件列非
10、索引1. select * from table where num = 200不加任何锁，是快照读。 2. select * from table where num 200不加任何锁，是快照读。 3. select * from table where num = 200 lock in share mode当num = 200，有两条记录。这两条记录对应的pId=2，7，因此在pId=2，7的聚簇索引上加行级S锁，采用当前读。 4. select * from table where num 200 lock in share mode当num 200，有一条记录。这条记录对应的pId=
11、3，因此在pId=3的聚簇索引上加上行级S锁，采用当前读。 5. select * from table where num = 200 for update当num = 200，有两条记录。这两条记录对应的pId=2，7，因此在pId=2，7的聚簇索引上加行级X锁，采用当前读。 6. select * from table where num 200 for update当num 200，有一条记录。这条记录对应的pId=3，因此在pId=3的聚簇索引上加上行级X锁，采用当前读。 RC/RU+条件列是聚簇索引恩，大家应该知道pId是主键列，因此pId用的就是聚簇索引。此情况其实和RC/RU+
12、条件列非索引情况是类似的。1. select * from table where pId = 2不加任何锁，是快照读。 2. select * from table where pId 2不加任何锁，是快照读。 3. select * from table where pId = 2 lock in share mode在pId=2的聚簇索引上，加S锁，为当前读。 4. select * from table where pId 2 lock in share mode在pId=3，7的聚簇索引上，加S锁，为当前读。 5. select * from table where pId = 2
13、for update在pId=2的聚簇索引上，加X锁，为当前读。 6. select * from table where pId 2 for update在pId=3，7的聚簇索引上，加X锁，为当前读。 为什么条件列加不加索引，加锁情况是一样的？其实是不一样的。在RC/RU隔离级别中，MySQL Server做了优化。在条件列没有索引的情况下，尽管通过聚簇索引来扫描全表，进行全表加锁。但是，MySQL Server层会进行过滤并把不符合条件的锁当即释放掉，因此你看起来最终结果是一样的。但是RC/RU+条件列非索引比本例多了一个释放不符合条件的锁的过程！RC/RU+条件列是非聚簇索引我们在nu
14、m列上建上非唯一索引。此时有一棵聚簇索引(主键索引，pId)形成的B+索引树，其叶子节点为硬盘上的真实数据。以及另一棵非聚簇索引(非唯一索引，num)形成的B+索引树，其叶子节点依然为索引节点，保存了num列的字段值，和对应的聚簇索引。接下来分析开始1. select * from table where num = 200不加任何锁，是快照读。 2. select * from table where num 200不加任何锁，是快照读。 3. select * from table where num = 200 lock in share mode当num = 200，由于num列上有索
15、引，因此先在 num = 200的两条索引记录上加行级S锁。接着，去聚簇索引树上查询，这两条记录对应的pId=2，7，因此在pId=2，7的聚簇索引上加行级S锁，采用当前读。 4. select * from table where num 200 lock in share mode当num 200，由于num列上有索引，因此先在符合条件的 num = 300的一条索引记录上加行级S锁。接着，去聚簇索引树上查询，这条记录对应的pId=3，因此在pId=3的聚簇索引上加行级S锁，采用当前读。 5. select * from table where num = 200 for update当num = 200，由于num列上有索引，因此先在 num = 200的两条索引记录上加行级X锁。接着，去聚簇索引树上查询，这两条记录对应的pId=2，7，因此在pId=2，7的聚簇索引上加行级X锁，采用当前读。 6. sel
