一文带你了解MySql并发事务中的数据库锁、隔离级别、MVCC

前言：

最近同事开发时遇到了一个事务阻塞的问题，经过网上查询发现关于MySQL事务、锁这一块的资料都比较絮乱，让人看的云里雾里，因此借着这个机会，恰好也对这一块内容作一个总结梳理，但愿能比较全面去写一下MySQL的并发事务处理。

本文主线：

• 简述事务的特性与隔离级别

• 聊聊MySql中各类类型的锁

• 而后再聊聊MVCC是个什么东东

• 接着再聊聊数据库锁的触发及升级，以及死锁

• 最后说下出现锁问题时的常见排查命令

简述事务的特性与隔离级别：

在讲锁以前，必需要先聊聊 事务的特性与隔离级别 ，由于锁机制的存在是为了保证事务对应隔离级别下的特性。

事务具备如下几个特性：

说完特性，再聊聊MySql中的几种事务隔离级别：

RU 读未提交：

顾名思义，在这种隔离级别下，当多个事务并行对同一数据进行操做时，会读取未提交的数据，也被称之为 脏读 。

这种隔离级别由于会出现脏读现象，因此在实际场景中不多用。

RC 读提交：

一个事务只能看见已经提交事务所作的改变。

但这种隔离级别会出现 不可重复读 现象，即在一个事务内，屡次读同一数据，在这个事务尚未结束时，若是另外一个事务刚好修改了这个数据，那么，在第一个事务中，两次读取的数据就可能不一致。

RR 可重复读：

这是MySQL的 默认事务隔离级别 ，在这种隔离级别下，解决了RC存在的不可重复读问题，确保在同一事务中，会看到一样的数据行。

但可能会出现 幻读 ，即当一个事务在执行读取操做，第一次查询数据总量后，另外一个事务执行了新增数据的操做并提交后，这个时候第一个事务读取的数据总量和以前统计的不同，就像产生幻觉同样。

SERIALIZABLE 串行化：

此隔离级别是四种隔离级别中最高的级别，解决了 脏读、可重复读、幻读 的问题。

可是性能最差，它将事务的执行变为顺序执行，与其余三个隔离级别相比，在并行事务执行过程当中，后一个事务的执行必须等待前一个事务结束。

MySql中各类类型的锁：

在MySQL中，按锁类型划分，有如下种类：

提到锁到种类，须要提一下MySQL到存储引擎，MySQL经常使用引擎有 MyISAM和InnoDB ，而InnoDB是mysql默认的引擎。MyISAM是不支持行锁的，而InnoDB支持行锁和表锁。

MyISAM 存储引擎下表锁：

MyISAM在执行查询语句（SELECT）前，会自动给涉及的全部表加读锁，在执行更新操做（UPDATE、DELETE、INSERT等）前，会自动给涉及的表加写锁；

读锁会阻塞对同一张表的写操做，而写锁既会阻塞对同一张表的写操做，也会阻塞此表的读操做。

排他锁、共享锁、意向锁 是什么东东？

排他锁：

一般咱们在InnoDB存储引擎中对表执行一个更新操做，针对这一行数据会持有排他锁；

持有排他锁时，不容许再在数据行上添加写锁与读锁，其余事务对此行数据的读、写操做都会被阻塞，只有当前事务提交了，锁释放了才容许其余事务进行读写，达到避免 脏读 的效果。

共享锁：

主要是为了支持并发的读取数据而出现的，当一个事务持有某一数据行的共享锁时，容许其它事务能够再获取共享锁，但不容许其它事务在此基础上获取排他锁；

也就是说，在持有共享锁时，多个事务能够同时读取当前数据，可是不容许任何事务同时对当前数据进行修改操做，阻塞添加排它锁。

意向锁：

首先须要明白一点，意向锁的做用是在 表上 的，当一个事务须要获取共享锁或排他锁时，首先要获取对应的意向锁；

为何要这样作呢？举个例子，假设在事务A中，对某一行数据添加共享锁，这一行只能读，不能写；此时事务B申请得到表的写锁，假如加锁成功，那么事务B将可以对整个表的数据进行读写，与事务A冲突，这种操做确定是不容许的呢；

因此MySQL会在申请共享锁或者排他锁的时候，先获取对应的意向锁，也就是说，你要操做表中的某一行锁数据，先要看看整个表能不能被操做；意向锁的申请是由数据库完成的，不须要人为申请。

Innodb 存储引擎下的行锁：

上文对几种锁类型进行了简要分析，其实平时工做开发中接触到最多的仍是行锁，行锁的实现有如下几种：

注意：在Innodb 存储引擎中，行锁的实现是基于索引的

Record Lock(记录锁)：

它是会锁住索引记录，好比 update table where id = 1， id 是主键，而后在聚簇索引上对 id=1 的个索引记录进行加锁；

Gap Lock(间隙锁)：

实质上是对索引先后的间隙上锁，不对索引自己上锁,目的是为了防止幻读。

当使用范围条件查询而不是等值条件检索数据，并请求排他锁、或共享锁时，对于该范围内不存在的记录，不容许其修改插入。

举个例子：当表中只有一条id=101的记录，一个事务执行select * from user where user_id > 100 for update；此时另外一个事务执行插入一条id=102的数据是会阻塞的，必须等待第一个事务提交后才能完成。

间隙锁是针对事务隔离级别为可重复读或以上级别的。

Next-Key Lock：

Next-Key Lock 是 记录锁和间隙锁 的结合，会同时锁住记录与间隙。

在innodb存储引擎中，若是没有经过 索引项 进行查询时：

①、在RR隔离级别下，会以Next-Key Lock的方式对数据行进行加锁，经过 行锁+间隙锁 实现了 "锁表" 的效果，但请记住这不是添加的表锁；

②、而在 RU、RC 隔离级别下仍是只会锁行记录，为何呢？由于在innodb存储引擎下的四种事务隔离级别中都支持行锁，可是间隙锁只存在于RR、Serializable 两种隔离级别下。

能够经过下面这篇文章了解为何在RR隔离级别下会实现"锁表"的效果，而在RC隔离级别下只会锁行记录: 互联网项目中mysql应该选什么事务隔离级别

MVCC 是什么：

锁机制能够控制并发操做，来保证一致性，可是系统开销会很大；在RC、RR的隔离级别下，MySQL的InnoDB存储引擎经过 MVCC (多版本并发控制) 机制来解决幻读。

使用MVCC时具体的体现是什么呢？

使事务在并发过程当中，SELECT 操做不用加锁，读写不冲突从而提升性能。

那么实现MVCC机制的原理是什么呢？

其原理是经过保存数据在某个时间点的快照来实现的；经过在每行记录后面保存隐藏列来存放事务ID，这样每个事务，都会对应一个递增的事务ID。

假设三个事务同时更新来同一行数据，那么就会对应三个数据版本，但实际上版本一、版本2并非物理存在的，而是经过关联记录在undo log 回滚日志中，这样就能够经过undo log找回数据的历史版本，好比回滚的操做，会使用上一个版本的数据覆盖数据页上的数据。

举例一个RR隔离级别下快照读的例子：

开启事务A按条件A查询到两条数据，此时事务B再插入1条数据且知足条件A的数据，并提交事务；

此时事务A再按条件A进行查询，查询到的依然是两条数据，也就是说，事务A查询到的并非当前最新的数据版本（三条数据），而是经过MVCC实现的历史快照版本；这也是可重复读的实现。

介绍了完读操做，再举例一个RR隔离级别下 更新 写操做的例子：

注意：对数据修改的操做(update、insert、delete)都会读到已提交事务的最新数据，由于这就是 当前读。

假设事务A执行一个更新语句，知足更新条件A（条件A字段无索引或者存在非惟一索引）的数据是2条，更新成功后不提交事务；

此时事务B插入一条新的知足条件A的数据时会被阻塞的，为何呢？

由于这里在事务A更新时使用到了Next-Key Lock锁，它会使用行锁+间隙锁实现了"锁表"，因此后面事务B再进行插入数据时会被阻塞的；这也防止了幻读的出现。

这里若是看的不是很明白的话，能够同时再参考下此文章，此文章详细分析了加锁状况：惊！史上最全的select加锁分析(Mysql)

注意：

MVCC只在RC和RR两个隔离级别下支持；其余两个隔离级别和MVCC不兼容，由于 RU老是读取最新的数据行，而不是符合当前事务版本的数据行；而S ERIALIZABLE 则会对全部读取的行都加锁，是当前读，也是读取的最新数据。

数据库锁的触发及升级，以及死锁：

数据库锁的触发及升级：

何时会出现DeadLock：

什么是死锁呢?

死锁是指两个或两个以上的进程在执行过程当中，因为竞争资源或者因为彼此通讯而形成的一种阻塞的现象，若无外力做用，它们都将没法推动下去。

此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。

举例说明：

事务A获取 id=20的锁，事务B获取id=30的锁，而后，事务A试图获取id=30的锁，而该锁已经被事务B持有，因此事务A等待事务 B释放该锁，而后事务B又试图获取id =20 的锁这个锁被事务 A 占有，因而两个事务之间相互等待，这就会致使死锁。

死锁的场景还有许多，归根结底，都是由于多个事务想要获取的锁互斥且获取的顺序不一致所形成。

如何避免死锁呢？

一般Record Lock引发的死锁问题开发时都会比较当心，但Gap Lock可能致使死锁的问题一般会被忽略，因此这一点要多加注意，另外就是创建合适的索引，若是没有索引,那么在操做数据时会锁住每一行，会增大死锁的几率。

出现锁问题时的常见排查命令：

show open tabbles：

SHOW OPEN TABLES where In_use > 0：查看哪些表被锁了

show status like 'table%'：

• table_locks_waited：出现表级锁定争用发生等待的次数，此值高说明存在验证的表记锁争用状况

• table_locks_immediate：表示当即释放表锁的次数

show status like 'innodb_row_lock%'：

• Innodb_row_lock_current_waits：当前正在等待锁定的数量

• Innodb_row_lock_time：系统启动到如今锁定总时间

• Innodb_row_lock_time_avg：每次等待话费的平均时间

• Innodb_row_lock_time_max：系统启动到如今等待最长一次所花时间

• Innodb_row_lock_waits：系统启动后到如今共等待次数

information_schema：

information_schema是MySQL专门记录性能信息的库，在5.7版本后默认打开。

• SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS： 查看当前InnoDB的锁的信息,会显示是什么锁类型,属于那个事务ID

• SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX： 查看InnoDB事务ID，会显示是什么操做和一些常规信息，例如是否在运行running,仍是等待锁

• SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS：查看InnoDB锁的等待时间，和等待的是哪一个事务ID的锁

♡ 点赞 + 评论 + 转发 哟

若是本文对您有帮助的话，请挥动下您爱发财的小手点下赞呀，您的支持就是我不断创做的动力，谢谢啦！

您能够微信搜索 【木子雷】 公众号，大量Java学习干货文章，您能够来瞧一瞧哟！