MySQL锁与脏读、不可重复读、幻读详解
最近，在一次 mysql 死锁的生产事故中，我发现，关于 mysql 的锁、事务等等，我所知道的东西太碎了，所以，我试着用几个例子将它们串起来。
具体做法就是通过不断地问问题、回答问题，再加上“适当”的比喻，来逐步构建脑子里的“知识树”。
需要提醒一下，这篇博客并不适合小白，因为你需要先了解排它锁、共享锁、事务，最重要的是你需要知道事务中的锁是什么时候加上、什么时候打开的。而这篇博客更多的是希望把这些碎片化的知识给连接起来。
项目环境
mysql 版本：5.7.28-winx64
OS：win 10
数据库脚本：
DROP TABLE IF EXISTS `demo_user`;
CREATE TABLE `demo_user` (
`id` varchar(32) NOT NULL COMMENT '用户id',
`name` varchar(16) NOT NULL COMMENT '用户名',
`gender` tinyint(1) DEFAULT '0' COMMENT '性别',
`age` int(3) unsigned DEFAULT NULL COMMENT '用户年龄',
`gmt_create` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '记录创建时间',
`gmt_modified` timestamp NULL DEFAULT NULL COMMENT '记录最近修改时间',
`deleted` tinyint(1) DEFAULT '0' COMMENT '是否删除',
`phone` varchar(11) NOT NULL COMMENT '电话号码',
PRIMARY KEY (`id`),
KEY `idx_phone` (`phone`),
KEY `idx_name` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';
insert into `demo_user`(`id`,`name`,`gender`,`age`,`gmt_create`,`gmt_modified`,`deleted`,`phone`) values ('222','zzs001',0,18,'2021-12-13 15:11:03','2021-12-13 09:59:12',0,'188******26');
insert into `demo_user`(`id`,`name`,`gender`,`age`,`gmt_create`,`gmt_modified`,`deleted`,`phone`) values ('111','zzf001'0,18,'2001-08-27 11:00:11','2001-08-27 11:00:13',0,'188******22');
一、MySQL锁
1、锁简介
锁是计算机协调多个进程或线程并发访问某一资源的机制。在数据库中，除传统的 计算资源（如CPU、RAM、I/O等）的争用以外，数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一 个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。从这个角度来说，锁对数据库而言显得尤其重要，也更加复杂。本章我们着重讨论MySQL锁机制 的特点，常见的锁问题，以及解决MySQL锁问题的一些方法或建议。
Mysql用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。这些锁统称为悲观锁(Pessimistic Lock)。
2、加锁的目的是什么
在我们了解数据库锁之前，首先我们必须要明白加锁的目的是为了解决什么问题，如果你还不清楚的话，那么从现在起你应该知道，数据库的锁是为了解决事务的隔离性问题，为了让事务之间相互不影响，每个事务进行操作的时候都会对数据加上一把特有的锁，防止其他事务同时操作数据。如果你想一个人静一静，不被别人打扰，那么请在你的房门上加上一把锁。
3、锁实是基于什么实现的
为了后面大家后面对锁理解的更透彻，所以务必要对此进行说明，锁是基于什么实现的，你现实生活中家里的锁是基于门来实现的，那么数据库的锁又是基于什么实现的呢？ 那么我在这里可以告诉你，数据库里面的锁是基于索引实现的，在Innodb中我们的锁都是作用在索引上面的，当我们的SQL命中索引时，那么锁住的就是命中条件内的索引节点(行锁)，如果没有命中索引的话，那我们锁的就是整个索引树（表锁），如下图一下锁住的是整棵树还是某几个节点，完全取决于你的条件是否有命中到对应的索引节点。
innodb索引结构图(B+ tree)：
4、锁的分类
数据库里有的锁有很多种，为了方面理解，所以我根据其相关性"人为"的对锁进行了一个分类，分别如下
基于锁的属性分类：共享锁、排他锁。
基于锁的粒度分类：表锁、行锁、记录锁、间隙锁、临键锁。
基于锁的状态分类：意向共享锁、意向排它锁。
1）属性锁
① 共享锁(Share Lock)
共享锁又称读锁，简称S锁；当一个事务为数据加上读锁之后，其他事务只能对该数据加读锁，而不能对数据加写锁，直到所有的读锁释放之后其他事务才能对其进行加持写锁。
共享锁的特性主要是为了支持并发的读取数据，读取数据的时候不支持修改，避免出现重复读的问题。
② 排他锁（eXclusive Lock）
排他锁又称写锁，简称X锁；当一个事务为数据加上写锁时，其他请求将不能再为数据加任何锁，直到该锁释放之后，其他事务才能对数据进行加锁。
排他锁的目的是在数据修改时候，不允许其他人同时修改，也不允许其他人读取。避免了出现脏数据和脏读的问题。
2）粒度锁
① 表锁
表锁是指上锁的时候锁住的是整个表，当下一个事务访问该表的时候，必须等前一个事务释放了锁才能进行对表进行访问。
特点： 粒度大，加锁简单，容易冲突。
② 行锁
行锁是指上锁的时候锁住的是表的某一行或多行记录，其他事务访问同一张表时，只有被锁住的记录不能访问，其他的记录可正常访问。
特点：粒度小，加锁比表锁麻烦，不容易冲突，相比表锁支持的并发要高。
③ 记录锁(Record Lock)
记录锁也属于行锁中的一种，只不过记录锁的范围只是表中的某一条记录，记录锁是说事务在加锁后锁住的只是表的某一条记录。
触发条件：精准条件命中，并且命中的条件字段是唯一索引；
例如：update user_info set name=’张三’ where id=1 ,这里的id是唯一索引。
记录锁的作用：加了记录锁之后数据可以避免数据在查询的时候被修改的重复读问题，也避免了在修改的事务未提交前被其他事务读取的脏读问题。
④ 间隙锁(Gap Lock)
间隙锁属于行锁中的一种，间隙锁是在事务加锁后其锁住的是表记录的某一个区间，当表的相邻ID之间出现空隙则会形成一个区间，遵循左开右闭原则。
比如下面的表里面的数据ID 为 1,4,5,7,10 ,那么会形成以下几个间隙区间，-n-1区间，1-4区间，7-10区间，10-n区间 （-n代表负无穷大，n代表正无穷大）。
触发条件：范围查询并且查询未命中记录，查询条件必须命中索引、间隙锁只会出现在REPEATABLE_READ（重复读)的事务级别中。
例如：对应上图的表执行select * from user_info where id>1 and id<4 for update(这里的id是唯一索引) ，这个SQL查询不到对应的记录，那么此时会使用间隙锁。
间隙锁作用：防止幻读问题，事务并发的时候，如果没有间隙锁，就会发生如下图的问题，在同一个事务里，A事务的两次查询出的结果会不一样。
⑤ 临键锁(Next-Key Lock)
临键锁也属于行锁的一种，并且它是INNODB的行锁默认算法，总结来说它就是记录锁和间隙锁的组合，临键锁会把查询出来的记录锁住，同时也会把该范围查询内的所有间隙空间也会锁住，再之它会把相邻的下一个区间也会锁住。
例如：下面表的数据执行 select * from user_info where id>1 and id<=13 for update ;
会锁住ID为 1,5,10的记录；同时会锁住，1至5,5至10,10至15的区间。
触发条件：范围查询并命中，查询命中了索引。
临键锁的作用：结合记录锁和间隙锁的特性，临键锁避免了在范围查询时出现脏读、重复读、幻读问题。加了临键锁之后，在范围区间内数据不允许被修改和插入。
3）状态锁
状态锁包括意向共享锁和意向排它锁，把他们区分为状态锁的一个核心逻辑，是因为这两个锁都是都是描述是否可以对某一个表进行加表锁的状态。
意向锁的解释：当一个事务试图对整个表进行加锁（共享锁或排它锁）之前，首先需要获得对应类型的意向锁（意向共享锁或意向共享锁）
① 意向共享锁
当一个事务试图对整个表进行加共享锁之前，首先需要获得这个表的意向共享锁。
② 意向排他锁
当一个事务试图对整个表进行加排它锁之前，首先需要获得这个表的意向排它锁。
为什么我们需要意向锁？
意向锁光从概念上可能有点难理解，所以我们有必要从一个案例来分析其作用，这里首先我们先要有一个概念那就是innodb加锁的方式是基于索引，并且加锁粒度是行锁，然后我们来看下面的案例。
第一步：
事务A对user_info表执行一个SQL:update user_info set name =”张三” where id=6 加锁情况如下图：
第二步：
与此同时数据库又接收到事务B修改数据的请求：SQL: update user_info set name =”李四”；
1、因为事务B是对整个表进行修改操作，那么此SQL是需要对整个表进行加排它锁的（update加锁类型为排他锁）；
2、我们首先做的第一件事是先检查这个表有没有被别的事务锁住，只要有事务对表里的任何一行数据加了共享锁或排他锁我们就无法对整个表加锁（排他锁不能与任何属性的锁兼容）。
3、因为INNODB锁的机制是基于行锁，那么这个时候我们会对整个索引每个节点一个个检查，我们需要检查每个节点是否被别的事务加了共享锁或排它锁。
4、最后检查到索引ID为6的节点被事务A锁住了，最后导致事务B只能等待事务A锁的释放才能进行加锁操作。
思考：
在A事务的操作过程中，后面的每个需要对user_info加持表锁的事务都需要遍历整个索引树才能知道自己是否能够进行加锁，这种方式是不是太浪费时间和损耗数据库性能了？
所以就有了意向锁的概念：如果当事务A加锁成功之后就设置一个状态告诉后面的人，已经有人对表里的行加了一个排他锁了，你们不能对整个表加共享锁或排它锁了，那么后面需要对整个表加锁的人只需要获取这个状态就知道自己是不是可以对表加锁，避免了对整个索引树的每个节点扫描是否加锁，而这个状态就是我们的意向锁。
5、不同的存储引擎支持不同的锁机制
相对其他数据库而言，MySQL的锁机制比较简单，其最 显著的特点是不同的存储引擎支持不同的锁机制。比如，MyISAM和MEMORY存储引擎采用的是表级锁（table-level locking）；BDB存储引擎采用的是页面锁（page-level locking），但也支持表级锁；InnoDB存储引擎既支持行级锁（row-level locking），也支持表级锁，但默认情况下是采用行级锁。
表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。
行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。
页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般
从上述特点可见，很难笼统地说哪种锁更好，只能就具体应用的特点来说哪种锁更合适！仅从锁的角度 来说：表级锁更适合于以查询为主，只有少量按索引条件更新数据的应用，如Web应用；而行级锁则更适合于有大量按索引条件并发更新少量不同数据，同时又有 并发查询的应用，如一些在线事务处理（OLTP）系统。
1）MyISAM表锁
MySQL的表级锁有两种模式：表共享读锁（Table Read Lock）和表独占写锁（Table Write Lock）。
对MyISAM表的读操作，不会阻塞其他用户对同一表的读请求，但会阻塞对同一表的写请求；对 MyISAM表的写操作，则会阻塞其他用户对同一表的读和写操作；MyISAM表的读操作与写操作之间，以及写操作之间是串行的！根据如表20-2所示的 例子可以知道，当一个线程获得对一个表的写锁后，只有持有锁的线程可以对表进行更新操作。其他线程的读、写操作都会等待，直到锁被释放为止。
MyISAM存储引擎的写锁阻塞读例子：当一个线程获得对一个表的写锁后，只有持有锁的线程可以对表进行更新操作。其他线程的读、写操作都会等待，直到锁被释放为止。
MyISAM存储引擎的读锁阻塞写例子：一个session使用LOCK TABLE命令给表film_text加了读锁，这个session可以查询锁定表中的记录，但更新或访问其他表都会提示错误；同时，另外一个session可以查询表中的记录，但更新就会出现锁等待。
① 如何加表锁
MyISAM在执行查询语句（SELECT）前，会自动给涉及的所有表加读锁，在执行更新操作 （UPDATE、DELETE、INSERT等）前，会自动给涉及的表加写锁，这个过程并不需要用户干预，因此，用户一般不需要直接用LOCK TABLE命令给MyISAM表显式加锁。在示例中，显式加锁基本上都是为了演示而已，并非必须如此。
给MyISAM表显示加锁，一般是为了在一定程度模拟事务操作，实现对某一时间点多个表的一致性读取。例如， 有一个订单表orders，其中记录有各订单的总金额total，同时还有一个订单明细表order_detail，其中记录有各订单每一产品的金额小计 subtotal，假设我们需要检查这两个表的金额合计是否相符，可能就需要执行如下两条SQL：
Select sum(total) from orders;
Select sum(subtotal) from order_detail;这时，如果不先给两个表加锁，就可能产生错误的结果，因为第一条语句执行过程中，order_detail表可能已经发生了改变。因此，正确的方法应该是：
Lock tables orders read local, order_detail read local;
Select sum(total) from orders;
Select sum(subtotal) from order_detail;
Unlock tables;要特别说明以下两点内容：
1. 上面的例子在LOCK TABLES时加了“local”选项，其作用就是在满足MyISAM表并发插入条件的情况下，允许其他用户在表尾并发插入记录，有关MyISAM表的并发插入问题，在后面还会进一步介绍。
2. 在用LOCK TABLES给表显式加表锁时，必须同时取得所有涉及到表的锁，并且MySQL不支持锁升级。也就是说，在执行LOCK TABLES后，只能访问显式加锁的这些表，不能访问未加锁的表；同时，如果加的是读锁，那么只能执行查询操作，而不能执行更新操作。其实，在自动加锁的 情况下也基本如此，MyISAM总是一次获得SQL语句所需要的全部锁。这也正是MyISAM表不会出现死锁（Deadlock Free）的原因。
当使用LOCK TABLES时，不仅需要一次锁定用到的所有表，而且，同一个表在SQL语句中出现多少次，就要通过与SQL语句中相同的别名锁定多少次，否则也会出错！举例说明如下。
（1）对actor表获得读锁：
mysql> lock table actor read;
Query OK, 0 rows affected (0.00 sec)（2）但是通过别名访问会提示错误：
mysql> select a.first_name,a.last_name,b.first_name,b.last_name
from actor a,actor b
where a.first_name = b.first_name and a.first_name = 'Lisa' and a.last_name = 'Tom'
and a.last_name <> b.last_name;ERROR 1100 (HY000): Table ‘a’ was not locked with LOCK TABLES（3）需要对别名分别锁定：
mysql> lock table actor as a read,actor as b read;Query OK, 0 rows affected (0.00 sec)（4）按照别名的查询可以正确执行：
mysql> select a.first_name,a.last_name,b.first_name,b.last_name
from actor a,actor b where a.first_name = b.first_name
and a.first_name = 'Lisa' and a.last_name = 'Tom'
and a.last_name <> b.last_name;+————+———–+————+———–+
| first_name | last_name | first_name | last_name |
+————+———–+————+———–+
| Lisa | Tom | LISA | MONROE |
+————+———–+————+———–+
1 row in set (0.00 sec)② 查询表级锁争用情况
可以通过检查table_locks_waited和table_locks_immediate状态变量来分析系统上的表锁定争夺：
mysql> show status like 'table%';Variable_name | Value
Table_locks_immediate | 2979
Table_locks_waited | 0
2 rows in set (0.00 sec))如果Table_locks_waited的值比较高，则说明存在着较严重的表级锁争用情况。
③ 并发插入（Concurrent Inserts）
上文提到过MyISAM表的读和写是串行的，但这是就总体而言的。在一定条件下，MyISAM表也支持查询和插入操作的并发进行。
MyISAM存储引擎有一个系统变量concurrent_insert，专门用以控制其并发插入的行为，其值分别可以为0、1或2。
当concurrent_insert设置为0时，不允许并发插入。
当concurrent_insert设置为1时，如果MyISAM表中没有空洞（即表的中间没有被删除的行），MyISAM允许在一个进程读表的同时，另一个进程从表尾插入记录。这也是MySQL的默认设置。
当concurrent_insert设置为2时，无论MyISAM表中有没有空洞，都允许在表尾并发插入记录。
在下面的例子中，session_1获得了一个表的READ LOCAL锁，该线程可以对表进行查询操作，但不能对表进行更新操作；其他的线程（session_2），虽然不能对表进行删除和更新操作，但却可以对该表进行并发插入操作，这里假设该表中间不存在空洞。
MyISAM存储引擎的读写（INSERT）并发例子：
可以利用MyISAM存储引擎的并发插入特性，来解决应 用中对同一表查询和插入的锁争用。例如，将concurrent_insert系统变量设为2，总是允许并发插入；同时，通过定期在系统空闲时段执行 OPTIMIZE TABLE语句来整理空间碎片，收回因删除记录而产生的中间空洞。
2）MyISAM的锁调度
前面讲过，MyISAM存储引擎的读锁和写锁是互斥的，读写操作是串行的。那么，一个进程请求某个 MyISAM表的读锁，同时另一个进程也请求同一表的写锁，MySQL如何处理呢？答案是写进程先获得锁。不仅如此，即使读请求先到锁等待队列，写请求后 到，写锁也会插到读锁请求之前！这是因为MySQL认为写请求一般比读请求要重要。这也正是MyISAM表不太适合于有大量更新操作和查询操作应用的原 因，因为，大量的更新操作会造成查询操作很难获得读锁，从而可能永远阻塞。这种情况有时可能会变得非常糟糕！幸好我们可以通过一些设置来调节MyISAM 的调度行为。
通过指定启动参数low-priority-updates，使MyISAM引擎默认给予读请求以优先的权利。
通过执行命令SET LOW_PRIORITY_UPDATES=1，使该连接发出的更新请求优先级降低。
通过指定INSERT、UPDATE、DELETE语句的LOW_PRIORITY属性，降低该语句的优先级。
虽然上面3种方法都是要么更新优先，要么查询优先的方法，但还是可以用其来解决查询相对重要的应用（如用户登录系统）中，读锁等待严重的问题。
另外，MySQL也提供了一种折中的办法来调节读写冲突，即给系统参数max_write_lock_count设置一个合适的值，当一个表的读锁达到这个值后，MySQL就暂时将写请求的优先级降低，给读进程一定获得锁的机会。
上面已经讨论了写优先调度机制带来的问题和解决办法。这 里还要强调一点：一些需要长时间运行的查询操作，也会使写进程“饿死”！因此，应用中应尽量避免出现长时间运行的查询操作，不要总想用一条SELECT语 句来解决问题，因为这种看似巧妙的SQL语句，往往比较复杂，执行时间较长，在可能的情况下可以通过使用中间表等措施对SQL语句做一定的“分解”，使每 一步查询都能在较短时间完成，从而减少锁冲突。如果复杂查询不可避免，应尽量安排在数据库空闲时段执行，比如一些定期统计可以安排在夜间执行。
3）InnoDB锁
InnoDB与MyISAM的最大不同有两点：一是支持事务（TRANSACTION）；二是采用了行级锁。行级锁与表级锁本来就有许多不同之处，另外，事务的引入也带来了一些新问题。
① 事务（Transaction）及其ACID属性
事务是由一组SQL语句组成的逻辑处理单元，事务具有4属性，通常称为事务的ACID属性。
原子性（Actomicity）：事务是一个原子操作单元，其对数据的修改，要么全都执行，要么全都不执行。
一致性（Consistent）：在事务开始和完成时，数据都必须保持一致状态。这意味着所有相关的数据规则都必须应用于事务的修改，以操持完整性；事务结束时，所有的内部数据结构（如B树索引或双向链表）也都必须是正确的。
隔离性（Isolation）：数据库系统提供一定的隔离机制，保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态对外部是不可见的，反之亦然。
持久性（Durable）：事务完成之后，它对于数据的修改是永久性的，即使出现系统故障也能够保持。
② 并发事务带来的问题
相对于串行处理来说，并发事务处理能大大增加数据库资源的利用率，提高数据库系统的事务吞吐量，从而可以支持可以支持更多的用户。但并发事务处理也会带来一些问题，主要包括以下几种情况。
更新丢失（Lost Update）：当两个或多个事务选择同一行，然后基于最初选定的值更新该行时，由于每个事务都不知道其他事务的存在，就会发生丢失更新问题——最后的更新覆盖了其他事务所做的更新。例如，两个编辑人员制作了同一文档的电子副本。每个编辑人员独立地更改其副本，然后保存更改后的副本，这样就覆盖了原始文档。最后保存其更改保存其更改副本的编辑人员覆盖另一个编辑人员所做的修改。如果在一个编辑人员完成并提交事务之前，另一个编辑人员不能访问同一文件，则可避免此问题。
脏读（Dirty Reads）：一个事务正在对一条记录做修改，在这个事务并提交前，这条记录的数据就处于不一致状态；这时，另一个事务也来读取同一条记录，如果不加控制，第二个事务读取了这些“脏”的数据，并据此做进一步的处理，就会产生未提交的数据依赖关系。这种现象被形象地叫做“脏读”。
不可重复读（Non-Repeatable Reads）：一个事务在读取某些数据已经发生了改变、或某些记录已经被删除了！这种现象叫做“不可重复读”。
幻读（Phantom Reads）：一个事务按相同的查询条件重新读取以前检索过的数据，却发现其他事务插入了满足其查询条件的新数据，这种现象就称为“幻读”。
③ 事务隔离级别
在并发事务处理带来的问题中，“更新丢失”通常应该是完全避免的。但防止更新丢失，并不能单靠数据库事务控制器来解决，需要应用程序对要更新的数据加必要的锁来解决，因此，防止更新丢失应该是应用的责任。
“脏读”、“不可重复读”和“幻读”，其实都是数据库读一致性问题，必须由数据库提供一定的事务隔离机制来解决。数据库实现事务隔离的方式，基本可以分为以下两种。
一种是在读取数据前，对其加锁，阻止其他事务对数据进行修改。
另一种是不用加任何锁，通过一定机制生成一个数据请求时间点的一致性数据快照（Snapshot），并用这个快照来提供一定级别（语句级或事务级）的一致性读取。从用户的角度，好像是数据库可以提供同一数据的多个版本，因此，这种技术叫做数据多版本并发控制（ＭultiVersion Concurrency Control，简称MVCC或MCC），也经常称为多版本数据库。
在MVCC并发控制中，读操作可以分成两类：快照读 (snapshot read)与当前读 (current read)。快照读，读取的是记录的可见版本 (有可能是历史版本)，不用加锁。当前读，读取的是记录的最新版本，并且，当前读返回的记录，都会加上锁，保证其他事务不会再并发修改这条记录。
在一个支持MVCC并发控制的系统中，哪些读操作是快照读？哪些操作又是当前读呢？以MySQL InnoDB为例：
快照读：简单的select操作，属于快照读，不加锁。(当然，也有例外)
select * from table where ?; - 当前读：特殊的读操作，插入/更新/删除操作，属于当前读，需要加锁。
下面语句都属于当前读，读取记录的最新版本。并且，读取之后，还需要保证其他并发事务不能修改当前记录，对读取记录加锁。其中，除了第一条语句，对读取记录加S锁 (共享锁)外，其他的操作，都加的是X锁 (排它锁)。
select * from table where ? lock in share mode;
select * from table where ? for update;
insert into table values (…);
update table set ? where ?;
delete from table where ?;数据库的事务隔离越严格，并发副作用越小，但付出的代价也就越大，因为事务隔离实质上就是使事务在一定程度上 “串行化”进行，这显然与“并发”是矛盾的。同时，不同的应用对读一致性和事务隔离程度的要求也是不同的，比如许多应用对“不可重复读”和“幻读”并不敏 感，可能更关心数据并发访问的能力。
为了解决“隔离”与“并发”的矛盾，ISO/ANSI SQL92定义了4个事务隔离级别，每个级别的隔离程度不同，允许出现的副作用也不同，应用可以根据自己的业务逻辑要求，通过选择不同的隔离级别来平衡 “隔离”与“并发”的矛盾。下表很好地概括了这4个隔离级别的特性。
④ 获取InonoD行锁争用情况
可以通过检查InnoDB_row_lock状态变量来分析系统上的行锁的争夺情况：
mysql> show status like 'innodb_row_lock%';
如果发现锁争用比较严重，如InnoDB_row_lock_waits和InnoDB_row_lock_time_avg的值比较高，还可以通过设置InnoDB Monitors来进一步观察发生锁冲突的表、数据行等，并分析锁争用的原因。
⑤ InnoDB的行锁模式及加锁方法
InnoDB实现了以下两种类型的行锁。
共享锁（s）：又称读锁。允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。若事务T对数据对象A加上S锁，则事务T可以读A但不能修改A，其他事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁。这保证了其他事务可以读A，但在T释放A上的S锁之前不能对A做任何修改。
排他锁（Ｘ）：又称写锁。允许获取排他锁的事务更新数据，阻止其他事务取得相同的数据集共享读锁和排他写锁。若事务T对数据对象A加上X锁，事务T可以读A也可以修改A，其他事务不能再对A加任何锁，直到T释放A上的锁。
对于共享锁大家可能很好理解，就是多个事务只能读数据不能改数据。
对于排他锁大家的理解可能就有些差别，我当初就犯了一个错误，以为排他锁锁住一行数据后，其他事务就不能读取和修改该行数据，其实不是这样的。排他锁指的是一个事务在一行数据加上排他锁后，其他事务不能再在其上加其他的锁。
mysql InnoDB引擎默认的修改数据语句：
update,delete,insert都会自动给涉及到的数据加上排他锁，select语句默认不会加任何锁类型，如果加排他锁可以使用select …for update语句，加共享锁可以使用select … lock in share mode语句。所以加过排他锁的数据行在其他事务种是不能修改数据的，也不能通过for update和lock in share mode锁的方式查询数据，但可以直接通过select …from…查询数据，因为普通查询没有任何锁机制。
另外，为了允许行锁和表锁共存，实现多粒度锁机制，InnoDB还有两种内部使用的意向锁（Intention Locks），这两种意向锁都是表锁。
意向共享锁（IS）：事务打算给数据行共享锁，事务在给一个数据行加共享锁前必须先取得该表的IS锁。
意向排他锁（IX）：事务打算给数据行加排他锁，事务在给一个数据行加排他锁前必须先取得该表的IX锁。
InnoDB行锁模式兼容性列表：
如果一个事务请求的锁模式与当前的锁兼容，InnoDB就请求的锁授予该事务；反之，如果两者两者不兼容，该事务就要等待锁释放。
意向锁是InnoDB自动加的，不需用户干预。对于UPDATE、DELETE和INSERT语句，InnoDB会自动给涉及数据集加排他锁（X)；对于普通SELECT语句，InnoDB不会加任何锁。
事务可以通过以下语句显式给记录集加共享锁或排他锁：
- 共享锁（S）：
SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE。 - 排他锁（X）：
SELECT * FROM table_name WHERE ... FOR UPDATE。
用SELECT ... IN SHARE MODE获得共享锁，主要用在需要数据依存关系时来确认某行记录是否存在，并确保没有人对这个记录进行UPDATE或者DELETE操作。但是如果当前事务也需要对该记录进行更新操作，则很有可能造成死锁，对于锁定行记录后需要进行更新操作的应用，应该使用SELECT… FOR UPDATE方式获得排他锁。
⑥ InnoDB行锁实现方式
InnoDB行锁是通过给索引上的索引项加锁来实现的，这一点MySQL与Oracle不同，后者是通过在数据块中对相应数据行加锁来实现的。InnoDB这种行锁实现特点意味着：只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁！
在实际应用中，要特别注意InnoDB行锁的这一特性，不然的话，可能导致大量的锁冲突，从而影响并发性能。下面通过一些实际例子来加以说明。
（1）在不通过索引条件查询的时候，InnoDB确实使用的是表锁，而不是行锁。
mysql> create table tab_no_index(id int,name varchar(10)) engine=innodb;Query OK, 0 rows affected (0.15 sec)mysql> insert into tab_no_index values(1,'1'),(2,'2'),(3,'3'),(4,'4');
Query OK, 4 rows affected (0.00 sec)Records: 4 Duplicates: 0 Warnings: 0
在上面的例子中，看起来session_1只给一行加了排他锁，但session_2在请求其他行的排他锁时，却出现了锁等待！原因就是在没有索引的情况下，InnoDB只能使用表锁。当我们给其增加一个索引后，InnoDB就只锁定了符合条件的行，如下所示。
创建tab_with_index表，id字段有普通索引：
mysql> create table tab_with_index(id int,name varchar(10)) engine=innodb;
mysql> alter table tab_with_index add index id(id);
（2）由于MySQL的行锁是针对索引加的锁，不是针对记录加的锁，所以虽然是访问不同行的记录，但是如果是使用相同的索引键，是会出现锁冲突的。应用设计的时候要注意这一点。
在下面的例子中，表tab_with_index的id字段有索引，name字段没有索引：
mysql> alter table tab_with_index drop index name;Query OK, 4 rows affected (0.22 sec) Records: 4 Duplicates: 0
Warnings: 0mysql> insert into tab_with_index values(1,'4');Query OK, 1 row affected (0.00 sec)mysql> select * from tab_with_index where id = 1;
InnoDB存储引擎使用相同索引键的阻塞例子：
（3）当表有多个索引的时候，不同的事务可以使用不同的索引锁定不同的行，另外，不论是使用主键索引、唯一索引或普通索引，InnoDB都会使用行锁来对数据加锁。
在下面的例子中，表tab_with_index的id字段有主键索引，name字段有普通索引：
mysql> alter table tab_with_index add index name(name);Query OK, 5 rows affected (0.23 sec) Records: 5 Duplicates: 0
Warnings: 0InnoDB存储引擎的表使用不同索引的阻塞例子：
（4）即便在条件中使用了索引字段，但是否使用索引来检索数据是由MySQL通过判断不同执行计划的代价来决 定的，如果MySQL认为全表扫描效率更高，比如对一些很小的表，它就不会使用索引，这种情况下InnoDB将使用表锁，而不是行锁。因此，在分析锁冲突 时，别忘了检查SQL的执行计划，以确认是否真正使用了索引。
比如，在tab_with_index表里的name字段有索引，但是name字段是varchar类型的，检索值的数据类型与索引字段不同，虽然MySQL能够进行数据类型转换，但却不会使用索引，从而导致InnoDB使用表锁。通过用explain检查两条SQL的执行计划，我们可以清楚地看到了这一点。
⑦ 间隙锁（Next-Key锁）
当我们用范围条件而不是相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据记录的 索引项加锁；对于键值在条件范围内但并不存在的记录，叫做“间隙（GAP)”，InnoDB也会对这个“间隙”加锁，这种锁机制就是所谓的间隙锁 （Next-Key锁）。
举例来说，假如emp表中只有101条记录，其empid的值分别是 1,2,…,100,101，下面的SQL：
Select * from emp where empid > 100 for update;是一个范围条件的检索，InnoDB不仅会对符合条件的empid值为101的记录加锁，也会对empid大于101（这些记录并不存在）的“间隙”加锁。
InnoDB使用间隙锁的目的，一方面是为了防止幻读，以满足相关隔离级别的要求，对于上面的例子，要是不使 用间隙锁，如果其他事务插入了empid大于100的任何记录，那么本事务如果再次执行上述语句，就会发生幻读；另外一方面，是为了满足其恢复和复制的需 要。有关其恢复和复制对锁机制的影响，以及不同隔离级别下InnoDB使用间隙锁的情况，在后续的章节中会做进一步介绍。
很显然，在使用范围条件检索并锁定记录时，InnoDB这种加锁机制会阻塞符合条件范围内键值的并发插入，这往往会造成严重的锁等待。因此，在实际应用开发中，尤其是并发插入比较多的应用，我们要尽量优化业务逻辑，尽量使用相等条件来访问更新数据，避免使用范围条件。
还要特别说明的是，InnoDB除了通过范围条件加锁时使用间隙锁外，如果使用相等条件请求给一个不存在的记录加锁，InnoDB也会使用间隙锁！下面这个例子假设emp表中只有101条记录，其empid的值分别是1,2,……,100,101。
InnoDB存储引擎的间隙锁阻塞例子：
对于MyISAM的表锁，主要讨论了以下几点：
（1）共享读锁（S）之间是兼容的，但共享读锁（S）与排他写锁（X）之间，以及排他写锁（X）之间是互斥的，也就是说读和写是串行的。
（2）在一定条件下，MyISAM允许查询和插入并发执行，我们可以利用这一点来解决应用中对同一表查询和插入的锁争用问题。
（3）MyISAM默认的锁调度机制是写优先，这并不一定适合所有应用，用户可以通过设置LOW_PRIORITY_UPDATES参数，或在INSERT、UPDATE、DELETE语句中指定LOW_PRIORITY选项来调节读写锁的争用。
（4）由于表锁的锁定粒度大，读写之间又是串行的，因此，如果更新操作较多，MyISAM表可能会出现严重的锁等待，可以考虑采用InnoDB表来减少锁冲突。
对于InnoDB表，本文主要讨论了以下几项内容：
（1）InnoDB的行锁是基于索引实现的，如果不通过索引访问数据，InnoDB会使用表锁。
（2）介绍了InnoDB间隙锁（Next-key)机制，以及InnoDB使用间隙锁的原因。
在不同的隔离级别下，InnoDB的锁机制和一致性读策略不同。
在了解InnoDB锁特性后，用户可以通过设计和SQL调整等措施减少锁冲突和死锁，包括：
（1）尽量使用较低的隔离级别； 精心设计索引，并尽量使用索引访问数据，使加锁更精确，从而减少锁冲突的机会；
（2）选择合理的事务大小，小事务发生锁冲突的几率也更小；
（3）给记录集显式加锁时，最好一次性请求足够级别的锁。比如要修改数据的话，最好直接申请排他锁，而不是先申请共享锁，修改时再请求排他锁，这样容易产生死锁；
（4）不同的程序访问一组表时，应尽量约定以相同的顺序访问各表，对一个表而言，尽可能以固定的顺序存取表中的行。这样可以大大减少死锁的机会；
（5）尽量用相等条件访问数据，这样可以避免间隙锁对并发插入的影响； 不要申请超过实际需要的锁级别；除非必须，查询时不要显示加锁；
（6）对于一些特定的事务，可以使用表锁来提高处理速度或减少死锁的可能。
二、脏读
在讲脏读之前，我们先开启两个会话，并把事务隔离级别更改为读未提交（read uncommitted）。这时，id 为 222 的用户初始年龄为 18。
脏读，就是读到了其他会话还没有提交的修改。下面用例子说明：
可以看到，会话 2 修改了 id 为 222 的用户，在还没提交或回滚事务之前，会话 1 就读到了这些改动。
脏读的本质就是，还没结束的写操作被读操作分割了。所以，为了解决脏读，就必须让写操作不可被读操作分割（当然，也不能被其他写操作分割），即保证所谓的原子性。
如何解决脏读
那么，应该如何实现呢？这里给出两种方案。
第一种，给读增加锁。为了保证写操作的原子性，从更新操作开始到事务结束（注意，不是事务开始到事务结束），会话 2 都应该锁着 id 为 222 的记录，会话 1 的读操作要等会话 2 的事务结束后才能执行。上面的例子中，我们理所当然地会认为是会话 2 的写操作没有加排它锁导致的脏读，然而并非如此，通过SELECT * FROM information_schema.INNODB_TRX;可以发现，会话 2 已经锁住了 id 为 222 的记录，但会话 1 的读操作并没有等待，为什么呢？根本原因在于会话 1 的读是无锁读，在读未提交的事务隔离级别中，无锁读不需要等待写操作。所以，我们需要给读加上锁（共享锁和排它锁均可，但为了并发读，建议用共享锁），如下：
可以看到，因为会话 2 的更新操作还没结束，所以，会话 1 需要一直等待，直到会话 2 的事务结束，这就避免了脏读的问题。你可能会觉得奇怪，实际项目好像不是这样的吧？没错，因为我们用的更多的是第二种方案。
第二种方案，将事务隔离级别更改为读已提交（read committed）。第一种方案中，读写是串行的，然而，我们既要读写并行，又不想出现脏读。需求刁钻但合理，于是，就有了第二种方案。如下：
可以看到，会话 2 的更新操作还没结束，会话 1 就读到了同一条记录，结果却没有产生脏读。如何实现的呢？
首先，我说说自己以前的理解：逻辑上有点像 java 中的CopyOnWriteArrayList，当事务隔离级别为已提交时，不会在实际记录上进行写操作，而是将需要修改的记录缓存一份进行更改，事务提交时才把这部分缓存刷入实际记录，而这个过程，其他会话可以正常读实际记录，而不会读到修改中的数据。
后来了解 MVCC 才知道我是错的，就 id 为 222 的这行数据，mysql 会同时保留多个版本，而此时的会话 1 只能看到更早的已提交版本。
三、不可重复读
在讲不可重复读之前，我们可以把事务隔离级别设置为读未提交（read uncommitted），也可以设置为读已提交（read committed）。
什么是不可重复读
不可重复读，就是在同一个事务中，多次读相同的记录但读到了不同的结果。下面用例子说明：
可以看到，会话 1 第一次读 id 为 222 的用户年龄为 18，在事务还没结束之前，会话 2 将他的年龄更改为 19，会话 1 再次读就会出现前后不一致的情况。
不可重复读的本质就是，还没结束的读操作被写操作分割了。所以，为了解决不可重复读，就必须让读操作不可被写操作分割，即保证所谓的原子性。
如何解决不可重复读
那么，应该如何实现呢？和解决脏数据一样，这里也给出两种方案。
第一种方案，给读增加锁来。为了保证读操作的原子性，从读操作开始到事务结束（注意，不是事务开始到事务结束），会话 1 都应该锁着 id 为 222 的记录，会话 2 的写操作要等会话 1 的事务结束后才能执行。所以，我们需要给读加上锁（共享锁和排它锁均可，但为了并发读，建议用共享锁），如下：
可以看到，会话 2 的写操作需要等待会话 1 的事务结束才能执行，在事务结束之前，会话 1 读几次数据都不会出现不可重复读。
第二种方案，将事务隔离级别更改为可重复读（repeatable read）。第一种方案中，读写是串行的，然而，我们既要读写并行，又不想出现不可重复读。于是，就有了第二种方案。如下：
可以看到，会话 1 的读操作并没有加锁，会话 2 的写操作也不需要等待，最终却没有产生不可重复读。如何实现的呢？
首先，我说说自己以前错误的理解：当第一次读到 id 为 222 的记录时，mysql 会把这条记录放在当前事务的缓存区里，下次读这条数据的时候直接从缓存拿就好，不需要去读实际记录，所以，其他会话的写操作并不需要等待。
不过，和解决脏读一样，这里也是用到了 MVCC。有人可能会问，同样是 MVCC 为什么，RR 可以解决可重复读，而 RC 不行，这里就要介绍一下MVCC。
MVCC
MVCC即为多版本并发控制，是一种用于提高并发量的方法，其可以有效的提高innodb引擎数据库的并发性能，做到即使有读写冲突，也能不加锁并发读。
1）什么是当前读和快照读
当前读：select lock in share mode(共享锁), select for update ; update, insert ,delete(排他锁)这些操作都是一种当前读，即读取当前的最新数据，为了保证数据是最新的，需要对读的数据加锁，不让其他事务在读的期间修改。
快照读：不加锁的select就是快照读，从字面理解，就是将数据取一份当前的快照，然后select这个快照上的数据，也不会加锁。当select数据时，此数据可能已经不是最新的了（被其他事务修改），显然此时的隔离级别不能是串行化，否则不会有其他事务并行修改。
2）为什么需要快照读
为了提高并发度，降低锁等待的时间。
3）如何实现快照度
利用MVCC，MVCC避免了加锁操作，降低了开销，实现了读写冲突时不加锁（仅限快照读）。
MVCC涉及的部分
1）MVCC的实现利用了每行记录的三个隐藏字段，分别时DB_TRX_ID(最近修改本行数据的事务id)，DB_ROLL_PTR(undo log带来的回滚指针，指向本行数据的上个版本)，DB_ROW_ID(本行数据的隐藏主键，如果没有主键，会以此主键生成表)。
ps，还有第四个隐藏字段 flag_delete,删除标记，实际删除由purge线程完成。
2）MVCC的实现还利用了Read VIew，Read View就是在进行快照读时生成一个事务快照，他会记录当前数据库内begin但未commit的事务id。这个View包含三部分，1，维护当前begin未commit的事务id的list ,记为trx_list ;2，list事务里的最小事务id，记为trx_min_id；3，View生成时刻，最大事务id+1的值，记为trx_max_id_plus ,也可以认为是下一个将要分配的事务id，需要注意的是这个最大事务是全局的，不是list里的事务，这与第二点不太相同。
Read View遵循可见性算法，具体规则如下：
1，事务id小于trx_min_id,那么此事务可见，
2，事务id大于trx_max_id_plus，此事务不可见
3，事务id是否在trx_list中，在则不可见，不在则可见。
三条规则依次判断,这里的可见和不可见指的是能否看到此事务修改的值。
3）MVCC的实现还利用了undo log，确切的说的update undo log。当update某行数据时，先加行锁，修改本行数据，然后将相应的undo log保存，同时回滚指针将指向undo log的位置，最后释放锁。如果希望获得update之前的数据，只需要将回滚指针指向的undo log应用到本行数据上即可。如果有多个版本的数据，那么会形成链表结构，链表最后端为最新数据，最前端为最老数据，不同版本之间也是通过回滚指针相连接。如果要获得最老的数据，就拿最新数据按照链表的顺序，一个一个的应用undo log即可。
MVCC的具体实现
结合图说
-
图中表示的是，一行数据的三个不同版本，其中字段1为a的是第一个版本，b为第二个版本，c为第三个版本，即当前版本
-
因为是同一行数据，所以主键和row_id在不同版本里是一样的，
-
roll_ptr为回滚指针，它指向的是上一个版本的数据位置
-
trx_id表明了是哪一个事务修改的本行数据。
此时 假设事务3（trx_id=3） select 本行数据，假设此时的read view 为{2，3，4}，那么首先获取最新版本数据的trx_id：9,由于9> 4+1,所以最新版本的数据c对事务3不可见；然后依据row_ptr指针找到本行数据的上一个版本，同理 由于trx_id 4 in read view，所以此版本依然不可见；最后依据回滚指针找到上上版本，此时trx_id：1< 2,所以此版本可见，那么此时select出的数据就是 a。
RR和RC下READ VIEW有何不同
从以上的流程可以看出 对于一个事务能读出那条数据，关键在于read view的内容。而read view的内容取决于read view生成的时间。
在RC下，事务在每一次进行快照读时，会生成一个read view, 如果在两次快照读之间有事务修改数据并commit，那么前后的两次快照读select这行数据的结果就会不同，这就是RC会出现不可重复读的原因，同一事务的两次读出现不一样的解决。
在RR下，当事务第一次进行快照读时，会生成一个read view，此后本事务内的所有快照读均使用该read view，不会再生成其他read view，所以在整个事务内，读同一行的数据不会有变化，这就解决了不可重复读问题。不可重复读对应的update操作，而如果是insert呢，RR也存在幻读的问题。对于这个问题可以用 串行化 解决，但是串行化效率太低，所以可以用间隙锁加插入意向锁解决。
四、MySQL如何实现事务隔离
众所周知，MySQL的在RR隔离级别下查询数据，是可以保证数据不受其它事物影响，而在RC隔离级别下只要其它事物commit后，数据都会读到commit之后的数据，那么事物隔离的原理是什么？是通过什么实现的呢？那肯定是通过MVCC机制（Multi-Version Concurrency Control，即多版本并发控制）。
MySQL的InnoDB引擎之所以能够支持高性能的并发性能，就是由于MySQL的MVCC机制（归功于undo log、Read-View）。
1、RC与RR隔离级别
我们分别开启RC与RR隔离级别实验说明，首先假设有account账户表，在事务ABC开启前，账户中的余额balance为1，即：
select balance from account =1; # 结果为11）RR事务隔离级别下查询结果
当在RR事务隔离级别分别开启三个事务，在不同时间段内做如下操作
- 事务A（显式开启事务，手动commit提交）：查询余额
- 事务B（显式开启事务，手动commit提交）：对id=1的余额加1
- 事务C（不显式开启事务，自动提交）：对id=1的余额加1
我们从时间逻辑上分为三个阶段，分析结果
- 第一阶段：事务A立马开始事务，随后事务B也紧跟着立马开始事务，然后事务C首先更新balance为2成功，当前balance=2；
- 第二阶段：事务B更新balance的值，此时先读到当前balance最新值为2，随后set balance=balance+1成功，当前balance=3；
- 第三阶段：事务A查询balance的值，此时的值为1（这里为什么等于1呢，是怎么实现的呢？不应该是当前最新值3吗？这就是本篇博文讨论的重点），最后commit结束事务，紧接着事务B也commit结束事务
最后事务A读取balance的结果是1，理所当然，RR即为可重复读，即一个事务在执行过程中看到的数据，总是跟这个事务启动时看到的数据是一致的，当前事务不管有没有提交，都不会影响数据，我只需要读取基于快照的数据即可，这就是快照读。但是我们要讨论的是如何在MVCC机制下实现？
注：begin/start transaction 命令并不是一个事务的起点，在执行到它们之后的第一个操作InnoDB表的语句，事务才真正启动。如果你想要马上启动一个事务，可以使用start transaction with consistent snapshot 这个命令。
2）RC事务隔离级别下查询结果
同样地，我们在RC隔离下，开启事务ABC，观察事务A最后的balance结果。
最后事务A读取balance的结果是2，理所当然，RC即为读可提交，字面意思就是其他事务只要提交后，当前事务我就能立马读取到最新当前值，这就是当前读。但是我们要讨论的是如何在MVCC机制下实现？
实际上这是因为实现MVCC时用到的一致性读视图，即consistent read view，用于支持RC（Read Committed，读提交）和RR（Repeatable Read，可重复读）隔离级别的实现。
2、事务隔离在MVCC的实现
在探讨MVCC如何实现事务隔离前，我们需要知道是视图数组、一致性视图等概念，才能帮助更好理解MVCC帮助事务实现了隔离。
1）数据行ROW的多版本
InnoDB里面每个事务有一个唯一的事务ID，叫作transaction id。它是在事务开始的时候向InnoDB的事务系统申请的，是按申请顺序严格递增的。
而每行数据也都是有多个版本的。每次事务更新数据的时候，都会生成一个新的数据版本，并且把transaction id赋值给这个数据版本的事务ID，记为row trx_id。同时，旧的数据版本要保留，并且在新的数据版本中，能够有信息可以直接拿到它（通过undo_log文件找到）。
也就是说，数据表中的一行记录，其实可能有多个版本(row)，每个版本有自己的row trx_id。
对某一个数据行ROW某个时刻经过三次更新事务的多版本控制流程，画如下图加深理解。
从图我们可以得到：
- ROW有四个版本V1-V4，即经过三次更新balance后，当前最新版本为V4，当前balance已经更新为4，是最新值
- InnoDB每次更新事务产生的transaction id都会赋值给row trx_id；
- 通过undo_log可以从V4撤回到V1,找到V1版本的balance=1，即undo_log回滚版本。
明白了数据行的ROW的多版本原理与实现后，可以帮助我们理解InnoDB是怎么定义并创建快照的！
2）视图数组
下述部分出自资料中的原句，特别是红色加深部分可能会比较难以理解，所以需要结合自己理解并画图。
InnoDB是这么在事务开启的时候定义快照的，哪些事务的操作我可以忽视，哪么我必须要保存在快照里。可以理解为：一个事务只需要在启动的时候声明说，“以我启动的时刻为准，如果一个数据版本是在我启动之前生成的，就认；如果是我启动以后才生成的，我就不认，我必须要找到它的上一个版本”。
在实现上， InnoDB为每个事务构造了一个数组，用来保存这个事务启动瞬间，当前正在“活跃”的所有事务ID。“活跃”指的就是，启动了但还没提交。数组里面事务ID的最小值记为低水位，当前系统里面已经创建过的事务ID的最大值加1记为高水位。这个视图数组和高水位，就组成了当前事务的一致性视图（read-view）。
我对低水位与高水位的理解：
低水位=当前所有启动了但未提交事务集合的ID最小值=当前事务的上一个启动但未提交的事务ID最小值（所有活跃事务ID最小值）
高水位=当前事务的ID（当前ROW版本号/row trx_id）=已经创建过事务ID的最大值+1
举例说明：仍然以上述RR隔离级别下三个ABC事务为例
- 事务A开始前，系统里面只有一个活跃事务ID是99；
- 事务A、B、C的版本号分别是100、101、102，且当前系统里只有这四个事务；
- 三个事务开始前，(id,balance)=(1,1）这一行数据的row trx_id是90。
这样，事务A的视图数组就是[99], 事务B的视图数组是[99,100], 事务C的视图数组是[99,100,101]。即视图数组通用公式为：[{当前事务开启瞬间活跃事务ID集合}]。
而数据版本的可见性规则，就是基于rowtrx_id和一致性视图对比结果得到的，所以我们还必须再了解下一致性视图。
3）一致性视图
通过对视图数组的理解，一致性视图就更加容易了，即：这个视图数组和高水位，就组成了当前事务的一致性视图（read-view）。
仍然以上述RR隔离级别下三个ABC事务为例
- 事务A开始前，系统里面只有一个活跃事务ID是99, 所以事物A开启瞬间活跃事物集合为[99]；
- 事务A、B、C的版本号分别是100、101、102，且当前系统里只有这四个事务，所以事物A、B、C高水位分别为100、101、102；
- 三个事务开始前，(id,balance)=(1,1）这一行数据的row trx_id是90。
这样，事务A的一致性视图就是[99,100], 事务B的一致性视图是[99,100,101], 事务C的一致性视图是[99,100,101,102]。即一致性视图通用公式为：[{当前事务开启瞬间活跃事务ID集合}，当前row trx_id]。
分析上述流程图结果：
第一个有效更新版本是事物C，更新balance=2，这个时候的最新版本rowtrx_id=102，而之前的在事物ABC之前的活跃事物最新版本row trx_id为99，所以此时99已经成为历史版本1。
第二个有效更新版本是事物B，更新balance=3，这个时候最新版本rowtrx_id=101，而此时row trx_id=102成为历史版本1，而rowtrx_id=99成为历史版本2。
事物A查询的时候，事物B是没有提交，但生成的(id, balance)=(1, 3)已经成为当前最新版本，事物A读取数据时，一致性视图为[99, 100]，而读数据都是从当前版本切的然后对比row trx_id，所以会有以下流程：
- 找到(1,3)的时候，判断出row trx_id=101，比高水位大，处于红色区域，不可见；
- 接着，找到上一个历史版本，一看row trx_id=102，比高水位大，处于红色区域，不可见；
- 再往前找，终于找到了（1,1)，它的row trx_id=90，比低水位小，处于绿色区域，可见。
最后事物A无论在什么时候查询，看到的数据都是一致性视图[99, 100]生成的快照数据(1, 1)，即rowtrx_id=90时的数据。这就称之为一致性读。
总结：
对于一个事务视图来说，除了自己的更新总是可见以外，有三种情况：
- 版本未提交，不可见；
- 版本已提交，但是是在视图创建后提交的，不可见；
- 版本已提交，而且是在视图创建前提交的，可见。
现在，我们用这个规则来判断图中的查询结果，事务A的查询语句的视图数组是在事务A启动的时候生成的，这时候：
- (1,3)还没提交，属于情况1，不可见；
- (1,2)虽然提交了，但是是在视图数组创建之后提交的，属于情况2，不可见；
- (1,1)是在视图数组创建之前提交的，可见。
3、当前读与快照读
1）当前读与快照读规则
当然按照这个一致性读的逻辑，事物B在事物C有效更新balance=2之后，但是事物B的视图数组是在事物C生成的，所以理论上来说不应该是事物B看到的是(id, balance)=(1, 1)这个数据（快照/历史版本）吗？而看不到当前版本(1, 2)数据。为什么事物B在更新balance之后直接数据就成为(1, 3)了呢？
如果事物B在update之前select一次数据，看到的值确实是balance=1，但是update是不能在历史版本上操作的，否则事物C的更新就会丢失，所以update操作都是在先读取当前版本，然后再更新。
也就说有这么一条规则：更新数据都是先读后更新，而这个读是读当前最新值，称之为“当前读（currentread），而只查询不读的话就会读取当前快照，称之为“快照读”。所以在事物B更新balance之前，先查询到最新的版本(1, 2)然后再更新为(1, 3)。而事物A查询的快照数据为(1, 1)，而不是最新版本(1, 3)。
2）当前读与快照读解释
当前读：像select lock in share mode(共享锁), select for update ; update, insert ,delete(排他锁)这些操作都是一种当前读。就是它读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。
快照读：像不加锁的select操作就是快照读，即不加锁的非阻塞读；快照读的前提是隔离级别不是串行级别，串行级别下的快照读会退化成当前读。是基于多版本控制的，那么快照读可能读到的并不一定是数据的最新版本，而有可能是之前的历史版本（快照数据）。
3）RC读可提交下的视图规则
读提交的逻辑和可重复读的逻辑类似，它们最主要的区别是：
在可重复读隔离级别下，只需要在事务开始的时候创建一致性视图，之后事务里的其他查询，都共用这个一致性视图；在读提交隔离级别下，每一个语句执行前都会重新算出一个新的视图，此时start transaction with consistent snapshot就等同于普通的starttransaction/begin所以在RC隔离级别下，事物A与事物B查询到的数据分别如下：
事物C立马更新balance=2，然后自动提交，生成最新版本(1, 2)，此时重新计算出视图数据(1, 2);事物B查到此时的最新版本为(1, 2)，之后再更新为版本(1, 3)为当前最新版本，查询此时的事物B select到的balance=3（事物B更新balance=3之后立马算出一个新的视图，select就是根据此视图得到的数据），而不是1。而此时事物B还未提交，对于事物A来说是看不见的，所以事物A此时读取到的事物C提交的最新版本(1, 2)。
五、幻读
我们知道MySQL在可重复读隔离级别下别的事物提交的内容，是看不到的。而可提交隔离级别下是可以看到别的事务提交的。而如果我们的业务场景是在事物内同样的两个查询我们需要看到的数据都是一致的，不能被别的事物影响，就使用可重复读隔离级别。这种情况下RR级别下的普通查询（快照读）依靠MVCC解决“幻读”问题，如果是“当前读”的情况需要依靠什么解决“幻读”问题呢？
注：下面讨论的“幻读”都是指在“可重复读”隔离级别下进行。
1、什么是幻读
假设我们有表t结构如下，里面的初始数据行为：(0,0,0),(1,1,1),(2,2,2),(3,3,3),(4,4,4),(5,5,5)
CREATE TABLE `t`
(
`id` INT(11) NOT NULL,
`key` INT(11) DEFAULT NULL,
`value` INT(11) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `value` (`value`)
) ENGINE = InnoDB;
INSERT INTO t
VALUES (0, 0, 0),
(1, 1, 1),
(2, 2, 2),
(3, 3, 3),
(4, 4, 4),
(5, 5, 5)假设select * from where value=1 for update，只在这一行加锁（注意这只是假设），其它行不加锁，那么就会出现如下场景：
Session A的三次查询Q1-Q3都是select * from where value=1 for update，查询的value=1的所有row。
- T1：Q1只返回一行(1,1,1)；
- T2：session B更新id=0的value为1，此时表t中value=1的数据有两行
- T3：Q3返回两行(0,0,1),(1,1,1)
- T4：session C插入一行(6,6,1)，此时表t中value=1的数据有三行
- T5：Q3返回三行(0,0,1),(1,1,1),(6,6,1)
- T6：session A事物commit。
其中Q3读到value=1这一样的现象，就称之为幻读，幻读指的是一个事务在前后两次查询同一个范围的时候，后一次查询看到了前一次查询没有看到的行。
先对“幻读”做出如下解释：
- 在可重复读隔离级别下，普通的查询是快照读，是不会看到别的事务插入的数据的。因此， 幻读在“当前读”下才会出现（三个查询都是for update表示当前读）；
- 上面session B的修改update结果，被session A之后的select语句用“当前读”看到，不能称为幻读，幻读仅专指“新插入的行”。
2、幻读有什么问题
（1）需要单独解决
众所周知，select ...for update语句就是将相应的数据行锁住，比如session A在T1时刻的Q1查询语句：select * from where value=1 for update就是将value=1的数据行锁住，但显然如果是上述的场景发生，此时的for update语义被破坏了（并没有锁住value=1的数据行）。
即使把所有的记录都加上锁，还是阻止不了新插入的记录，所以“幻读”问题要单独拿出来解决。没法依靠MVCC或者行锁机制来解决。这就引出“间隙锁”，是另外一种加锁机制。
（2）间隙锁引发的并发度
间隙锁引入以后，可能会导致同样语句锁住更大的范围，这可能就会影响了并发度。
3、如何解决幻读
产生幻读的原因是，行锁只能锁住行，但是新插入记录这个动作，要更新的是记录之间的“间隙”。因此，为了解决幻读问题，InnoDB只好引入新的锁，也就是间隙锁(Gap Lock)。
间隙：比如表中加入6个记录，0,5,10,15,20,25。则产生7个间隙：
在一行行扫描的过程中，不仅将给行加上了行锁，还给行两边的空隙也加上了间隙锁。这样就确保了无法再插入新的记录。
间隙锁和行锁合称next-key lock，每个next-key lock是前开后闭区间（间隙锁开区间，next-key lock前开后闭区间）：
间隙锁与间隙锁之间是不存在冲突的，冲突的是往间隙里插入一条记录。
表t中是没有value=7这个数据的，所以Q1加的间隙锁(1,5)，而Q2也是加的这个间隙锁，两者不冲突都是为了保护这个间隙不允许插入值。
在表t初始化后，假设表的数据如下：
如果用select * from for update执行，则会把整个表所有记录锁起来，就形成了7个next-key lock，分别是(-∞,0]、(0,2]、(2,4]、(4,6]、(6,8]、(8, 10]、(10, +supremum]
间隙锁的引入，可能会导致同样的语句锁住更大的范围，是会影响了并发度。
假设发生如下场景：
则明显发生了死锁，分析如下：
- Q1：执行select …for update语句，由于id=9这一行并不存在，因此会加上间隙锁 (8,10);
- Q2：执行select …for update语句，同样会加上间隙锁(8,10)，间隙锁之间不会冲突，因 此这个语句可以执行成功；
- session B 试图插入一行(9,9,9)，被session A的间隙锁挡住了，只好进入等待；
- session A试图插入一行(9,9,9)，被session B的间隙锁挡住了。
有上述可知间隙锁的引入，可能会导致同样语句锁住更大的范围，这其实是影响了并发度。
为了解决幻读问题可以采用读可提交隔离级别，间隙锁是在可重复读隔离级别下才会生效的。所以如果把隔离级别设置为读提交的话， 就没有间隙锁了。但同时，你要解决可能出现的数据和日志不一致问题，需要把binlog格式设置为row，也就是说采用“RC隔离级别+日志格式binlog_format=row”组合。
总结：
- RR隔离级别下间隙锁才有效，RC隔离级别下没有间隙锁；
- RR隔离级别下为了解决“幻读”问题：“快照读”依靠MVCC控制，“当前读”通过间隙锁解决；
- 间隙锁和行锁合称next-key lock，每个next-key lock是前开后闭区间；
- 间隙锁的引入，可能会导致同样语句锁住更大的范围，影响并发度。