当多个用户对数据库进行操作时，会带来数据不一致的情况，所以，锁主要是在多用户情况下保证数据库 数据完整性和一致性。

数据库的事务隔离就需要用到数据库锁，当插入数据时，就锁定表，这叫做”锁表”；当更新数据时， 就锁定行，这叫做”锁行”。

锁分类

按照不同的分类标准，有不同的锁类型，汇总如下：

属性划分：读写锁

在多用户并发操作数据库的时候，可能出现一个读取、另外一个修改的操作， 为了避免出现读取错误的数据， 需要进行并发控制，可以通过实现一种由两种类型的锁组成的锁系统来解决问题。这两种类型的锁通常被称为 共享锁(share lock)和排他锁(exclusive lock)，也叫做读锁(read lock)和写锁(write lock)。

读锁（共享锁）

共享锁，又称之为读锁，简称S锁，当事务对数据加上读锁后，其他事务只能对该数据加读锁， 不能做任何修改操作，也就是不能添加写锁。只有当数据上的读锁被释放后，其他事务才能对其添加写锁。 共享锁主要是为了支持并发的读取数据而出现的，读取数据时，不允许其他事务对当前数据进行修改操作， 从而避免”不可重读”的问题的出现。

读锁是共享的，或者说是相互不阻塞的。多个客户可以再同一时间读取同一个资源，而互不干扰。

写锁（排他锁）

排它锁，又称之为写锁，简称X锁，当事务对数据加上写锁后，其他事务既不能对该数据添加读写， 也不能对该数据添加写锁，写锁与其他锁都是互斥的。只有当前数据写锁被释放后，其他事务才能 对其添加写锁或者是读锁。写锁主要是为了解决在修改数据时，不允许其他事务对当前数据进行 修改和读取操作，从而可以有效避免”脏读”问题的产生。

写锁是排他的，也就是说一个写锁会阻塞其他的写锁和读锁，这是出于安全策略的考虑。

汇总

当我们使用sql语句做查询操作，命中索引则添加行锁，此时，共享指定行；没有命中索引则添加表锁， 则共享整张表。通过上图我们知道，共享锁只能兼容共享锁，不兼容排它锁，并且，排它锁互斥共享锁和 其它排它锁。我们在数据库操作一遍试试看：

如上图所示，我们写个查询的sql语句，此时应用的是共享锁，共享锁是排斥排它锁的， 此时对指定行做修改操作时，应该是不能修改的，但是我们通过sql语句亲测后， 我们发现还是可以插入数据的，这个很明显违反了共享锁和排它锁的基本原则，这个是怎么回事呢？

其实，在这里面，还有一个叫做MVCC的东西，因为锁是一个非常耗性能的东西，每次都得去加锁和释放锁， 为了提高数据库的并发性，所以出现了MVCC，这个我们在下一章节中讲。

虽然我们演示没有出现预期的效果，但是数据库共享锁和排它锁依然是存在的，有了MVCC我们在查询数据的时候， 可以修改数据，我们在修改数据的时候，可以查询数据。也就是说，有读锁，依然可以使用写锁；有写锁， 依然可以使用读锁；但是，在有写锁的情况下，其他事务不能再对当前数据添加写锁，因为要保证数据的一致性。 我们代码测试一下：

锁粒度

一种提高共享资源并发的方式就是让锁定对象更具有选择性。尽量只锁定需要修改的部分数据，而不是所有的 资源。更理想的方式是，只对会修改的数据片进行精确的锁定。任何时候，锁定的数据量越少，则系统的并发 性越高，只要相互之间不发生冲突即可。

问题是加锁也需要消耗资源，锁的各种操作，包括获取锁、检查锁是否已经解除、释放锁，都会增加系统的开 销。如果系统需要花费大量的时间来管理锁，而不是存取数据，那么系统的性能就会因此受到影响。

所谓的锁策略，就是在锁的开销和数据的安全性之间寻求平衡，这种平衡当然也会影响到性能。

行锁

行级锁可以最大程度的支持并发处理，同时也带来了最大的锁开销。在 InnoDB 和 XtraDB，以及其他 一些存储引擎中实现了行级锁，而且只在存储引擎层实现。服务器层完成不了解存储引擎中的锁实现。

顾名思义，行锁就是一锁锁一行或者多行记录，mysql的行锁是基于索引加载的， 所以行锁是要加在索引响应的行上，即命中索引，如下图所示：

如上图所示，数据库表中有一个主键索引和一个普通索引，Sql语句基于索引查询，命中两条记录。 此时行锁一锁就锁定两条记录，当其他事务访问数据库同一张表时，被锁定的记录不能被访问， 其他的记录都可以访问到。

行锁的特征：锁冲突概率低，并发性高，但是会有死锁的情况出现。

我们使用代码演示一下，看看行锁的表现：我们还是使用上一篇文章中使用的数据库，打开两个窗口， 我们在窗口A中根据id更新一条记录，然后在窗口B中也执行相同的SQL语句看看：

可以看到，窗口A先修改了id为3的用户信息后，还没有提交事务，此时窗口B再更新同一条记录，然后就提示 Lock wait timeout exceeded; try restarting transaction ，由于窗口A迟迟没有提交事务， 导致锁一直没有释放，就出现了锁冲突，而窗口B一直在等待锁，所以出现了超过锁定超时的警告了。

但是，此时我们如果去更新id为3它旁边的记录看看会出现怎样的情况，我们新打开一个窗口更新id为2的记录看看。

可以看到，在窗口B中更新id为3的记录报错，但是在窗口C中我们可以更新id为2的记录， 这说明此时锁定了id为3的记录但是并没有锁定它旁边的记录。

表锁

表锁(table lock)，表锁是 MySQL 中最基本的锁策略，并且是开销最小的策略。顾名思义，当一个用户 在对表进行写操作（插入、删除、更新等），就会锁定整张表，这会阻塞其他用户对该表的所有读写操作。 只有没有写锁时，其他读取的用户才能获得读锁，读锁之间是不相互阻塞的。

在特定场景中，表锁也可能有良好的性能。比如：READ LOCAL 表锁支持某些类型的并发写操作。另外， 写锁比读锁有更高的优先级，因此一个写锁请求可能会被插入到读锁队列的前面（反之，读锁则不能插入到 写锁前面）

尽管存储引擎可以管理自己的锁，但是 MySQL 会使用各种有效的表锁来实现不同的目的。比如，服务器会 为诸如 ALTER TABLE 之类的语句使用表锁，而忽略存储引擎的锁机制。

顾名思义，表锁就是一锁锁一整张表，在表被锁定期间，其他事务不能对该表进行操作， 必须等当前表的锁被释放后才能进行操作。表锁响应的是非索引字段，即全表扫描， 全表扫描时锁定整张表，sql语句可以通过执行计划看出扫描了多少条记录。

由于表锁每次都是锁一整张表，所以表锁的锁冲突几率特别高，表锁不会出现死锁的情况。 我们通过代码演示一下，看看表锁的表现，我们打开两个窗口，在窗口A中更新一条记录， 条件为非索引字段，不提交事务，然后在窗口B中任意再更新一条记录，我们看看会出现怎样的现象：

总的来说，当更新数据库数据时，如果没有触发索引，则会锁表，锁表后再对表做任何变更操作都会导致锁冲突， 所以表锁的锁冲突概率较高。

死锁

非权威解释： 死锁是指多个事务在同一资源上相互占用并请求锁定对方占用的资源而导致恶性循环的现象。当多个事 务试图以不同顺序锁定资源时就可能会产生死锁，多个事务同时锁定同一个资源时也会产生死锁。 为了解决死锁问题，数据库系统实现了各种死锁检测和死锁超时机制。越复杂的系统，例如InnoDB 存储引擎，越能检测到死锁的循环依赖，并立即返回一个错误。这种解决方式很有效，否则死锁会导致出 现非常慢的查询。还有一种解决方法，就是当查询的时间达到锁等待超时的设定后放弃锁请求，这种方 式通常来说不太好。InnoDB 目前处理死锁的方法是将持有最少行级排它锁的事务进行回滚。 死锁发生之后，只有部分或者完全回滚其中一个事务，才能打破死锁。对于事务型系统这是无法避免的， 所以应用程序在设计时必须考虑如何处理死锁。大多数情况下只需要重新执行因死锁回滚的事务即可。

行锁划分

在mysql中，行锁又衍生了其他几种算法锁，分别是 记录锁、间隙锁、临键锁； 我们依次来看看这三种锁，什么是记录锁呢？

记录锁

上面我们找到行锁是命中索引，一锁锁的是一张表的一条记录或者是多条记录，记录锁是在行锁上衍生的锁， 我们来看看你记录锁的特征: 记录锁锁的是表中的某一条记录，记录锁的出现条件必须是精准命中索引并且索引是唯一索引，如主键id， 就像我们上面描述行锁时使用的sql语句图，在这里就挺适用的。

图中id是唯一索引，此时锁的就是一条记录，命中索引为唯一索引，此时使用的锁就是记录锁了。 相信学习完行锁后，再学习记录锁就简单很多了吧。

间隙锁

间隙锁又称之为区间锁，每次锁定都是锁定一个区间，隶属行锁。既然间隙锁隶属行锁，那么， 间隙锁的触发条件必然是命中索引的，当我们查询数据用范围查询而不是相等条件查询时， 查询条件命中索引，并且没有查询到符合条件的记录，此时就会将查询条件中的范围数据进行锁定 (即使是范围库中不存在的数据也会被锁定)，我们通过代码演示一下：

首先，我们打开两个窗口，在窗口A中我们根据id做一个范围更改操作，不提交事务， 然后在范围B中插入一条记录，该记录的id值位于窗口A中的条件范围内，我们看看运行效果：

如上所示，程序报错：Lock wait timeout exceeded; try restarting transaction 。 这就是间隙锁的作用。间隙锁只会出现在可重复读的事务隔离级别中，mysql5.7默认就是可重复读。 间隙锁锁的是一个区间范围，查询命中索引但是没有匹配到相关记录时，锁定的是查询的这个区间范围， 上述代码中，所锁定的区间就是 (1,3]这个区间,不包含1，但是包含3，并且不包含4，也就是说 这里是一个左开右闭的区间。

如果我们将mysql数据库隔离级别修改为不可重复读，然后再运行一下上面代码，看看会是怎样的呢， 我们来验证一下间隙锁只会出现在可重复读的事务隔离级别中：

# 设置事务隔离级别为不可重复读
set session transaction isolation level read committed;
# 查看当前事务级别
SELECT @@tx_isolation

我们修改数据库隔离级别后，然后将上面的代码流程再走一遍看看：

临键锁

学习完间隙锁后我们再来看看什么是临键锁，mysql的行锁默认就是使用的临键锁，临键锁 是由记录锁和间隙锁共同实现的，上面我们学习间隙锁时，间隙锁的触发条件是命中索引， 范围查询没有匹配到相关记录。而临键锁恰好相反，临键锁的触发条件也是查询条件命中索引， 不过，临键锁有匹配到数据库记录；

上面我们知道，间隙锁所锁定的区间是一个左开右闭的集合，而临键锁锁定是当前记录的区间和 下一个记录的区间，我们一起来看看：

从上图我们可以看到，数据库中只有三条数据1、5、7，当修改范围为1~8时，则锁定的区间为(1,+∞)， 锁定的不单是查询范围，并且还锁定了当前范围的下一个范围区间，此时，查询的区间8， 在数据库中是一个不存在的记录值，并且，如果此时的查询条件是小于或等于8，也是一样的锁定8到后面的区间。

如果查询的结尾是一个存在的值，此时又会怎样呢？现在数据库有三条数据id分别是1、5、7， 我们查询条件改为大于1小于7再看看。

此时，我们可以看到，由于7在数据库中是已知的记录，所以此时的锁定后，只锁定了(1,7]， 7之后的数据都没有被锁定。我们还是可以正常插入id为8的数据及其后面的数据。

所以，临键锁锁定区间和查询范围后匹配值很重要，如果后匹配值存在，则只锁定查询区间， 否则锁定查询区间和后匹配值与它的下一个值的区间。

但是，为什么会出现这种情况呢？为什么临键锁后匹配会这样呢？在这里，我们不妨看看mysql的索引 是怎么实现的，前面文章中有提到树结构，mysql的索引是基于B+树实现的，每个树节点上都有多个元素， 即关键字数，当我们的索引树上只有1、5、7时，我们查询1~8，这个时候由于树节点关键字中并没有8， 所以就把8到正无穷的区间范围都给锁定了。

那么，如果我们数据库中id有1、5、7、10，此时我们再模糊匹配id为1~8的时候，由于关键字中并没有8， 所以找比8大的，也就找到了10，根据左开右闭原则，此时10也是被锁定的，但是id为11的记录还是可以 正常进行插入的。这里我没有测试，感兴趣的朋友可以下去自己尝试一下。我们的锁都是基于索引的， 而mysql中索引的底层是使用的B+树，我们了解了B+树的特性后，就更容易理解很多遇到锁的问题了。

参考资料

• MySQL 锁机制
• MySQL 多版本并发控制 MVVC
• 高性能MySQL
• 深入理解数据库行锁与表锁