Mysql数据库的隔离级别的底层实现与锁的关系

一、概念

      脏读：指读到了其他事务未提交的数据。

      不可重复读：读到了其他事务已提交的数据（其他事务对该条数据进行了update操作这种情况）。

      幻读：在一个事务中，两次同样的select操作的结果，row数不一致。

       不可重复读和幻读都是读到了其他事务已提交的数据，但是针对的点不一样，

       不可重复读是对update

       幻读是对delete和insert。

二、现象

       脏读：

       

      不可重复读：

       

       幻读：

       

三、原因

      先说四种隔离级别

       

未提交读造成脏读：根据“未提交读（READ UNCOMMITTED）是最低的隔离级别，在这种隔离级别下，如果一个事务已经开始                            写数据，则另外一个事务则不允许同时进行写操作，但允许其他事务读此行数据。”  

                         

已提交读造成不可重复读：根据“在已提交读（READ COMMITTED）级别中，读取数据的事务允许其他事务继续访问该行数                                 据，    但是未提交的写事务将会禁止其他事务访问该行，会对该写锁一直保持直到到事务提交。”

                        判断出事务1读的时候先加读锁，写的时候加写锁，所以事务2提交前一直阻塞事务1的读，避免事务1脏读。

                        同样，来分析不可重复读，事务1读取id=1的数据后并没有锁住该数据，所以事务2能对这条数据进行更新，事务2                          对更新并提交后，该数据立即生效，所以事务1再次执行同样的查询，查询到的结果便与第一次查到的不同，所以                          已提交读防不了不可重复读。

可串行化防止所有：可串行化（Serializable ）是高的隔离级别，它求在选定对象上的读锁和写锁保持直到事务结束后才能释                                  放，     所以能防住上诉所有问题，但因为是串行化的，所以效率较低。

                          RU、RC级别都是在事务未提交就释放了锁，比如RU级别是在事务2未提交就释放了写锁，从而导致事务1可以                               读到数据，造成脏读；RC级别是在事务1未提交就释放了读锁，从而导致事务2可以加写锁，从而导致不可重复                            读。

四、可重复读能不能防住幻读？及详解

===================================重点来了=========================================

                           可重复读RR级别下究竟能不能防住幻读？

 

从上图看到，这种情况下，RR级别既防住了不可重复读又防住了幻读。

悲观锁与乐观锁

悲观锁

正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。

 

读取数据时给加锁，其它事务无法修改这些数据。修改删除数据时也要加锁，其它事务无法读取这些数据。

---

 

我们前面说的在对象上加锁，是一种悲观锁机制。

 

有很多文章说可重复读的隔离级别防不了幻读，是认为可重复读会对读的行加锁，导致他事务修改不了这条数据，直到事务结束。

 

但是这种方案只能锁住数据行，如果有新的数据进来，是阻止不了的，所以会产生幻读

可是MySQL、ORACLE、PostgreSQL等已经是非常成熟的数据库了，怎么会单纯地采用这种如此影响性能的方案呢?

---

乐观锁

相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。

 

但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。

 

而乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本（ Version ）记录机制实现。

 

何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。

 

此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。

 

MySQL、ORACLE、PostgreSQL等都是使用了以乐观锁为理论基础的MVCC（多版本并发控制）来避免不可重复读和幻读,MVCC的实现没有固定的规范，每个数据库都会有不同的实现方式，这里讨论的是InnoDB的MVCC。

 

MVCC(多版本并发控制)

在InnoDB中，会在每行数据后添加两个额外的隐藏的值来实现MVCC，这两个值一个记录这行数据何时被创建，另外一个记录这行数据何时过期（或者被删除）。

 

在实际操作中，存储的并不是时间，而是事务的版本号，每开启一个新事务，事务的版本号就会递增。在可重读Repeatable reads事务隔离级别下：

• SELECT时，读取创建版本号<=当前事务版本号，删除版本号为空或>当前事务版本号。

• INSERT时，保存当前事务版本号为行的创建版本号

• DELETE时，保存当前事务版本号为行的删除版本号

• UPDATE时，插入一条新纪录，保存当前事务版本号为行创建版本号，同时保存当前事务版本号到原来删除的行

通过MVCC，虽然每行记录都要额外的存储空间来记录version，需要更多的行检查工作以及一些额外的维护工作，但可以减少锁的使用，大多读操作都不用加锁，读取数据操作简单，性能好。

 

细心的同学应该也看到了，通过MVCC读取出来的数据其实是历史数据，而不是最新数据。

 

这在一些对于数据时效特别敏感的业务中，很可能出问题，这也是MVCC的短板之处，有办法解决吗？当然有。

 

MCVV这种读取历史数据的方式称为快照读(snapshot read)，而读取数据库当前版本数据的方式，叫当前读(current read)。

快照读

我们平时只用使用select就是快照读，这样可以减少加锁所带来的开销。

•  

select * from table ....

当前读

 

对于会对数据修改的操作(update、insert、delete)都是采用当前读的模式。在执行这几个操作时会读取最新的记录，即使是别的事务提交的数据也可以查询到。

 

假设要update一条记录，但是在另一个事务中已经delete掉这条数据并且commit了，如果update就会产生冲突，所以在update的时候需要知道最新的数据。读取的是最新的数据，需要加锁。

 

以下第一个语句需要加共享锁，其它都需要加排它锁。

select * from table where ? lock in share mode; select * from table where ? for update; insert; update; delete;

Next-Key锁

在Users这张表里面，class_id是个非聚簇索引，数据库会通过B+树维护一个非聚簇索引与主键的关系，简单来说，我们先通过class_id=1找到这个索引所对应所有节点，这些节点存储着对应数据的主键信息，即id=1，我们再通过主键id=1找到我们要的数据，这个过程称为回表。

前往学习: 

https://www.cnblogs.com/sujing/p/11110292.html

我本想用我们文章中的例子来画一个B+树，可是画得太丑了，为了避免拉低此偏文章B格。所以我想引用上面那边文章中作者画的B+树来解释Next-key。

 

假设我们上面用到的User表需要对Name建立非聚簇索引，是怎么实现的呢？我们看下图：

B+树的特点是所有数据都存储在叶子节点上，以非聚簇索引的秦寿生为例，在秦寿生的右叶子节点存储着所有秦寿生对应的Id，即图中的34。

 

在我们对这条数据做了当前读后，就会对这条数据加行锁，对于行锁很好理解，能够防止其他事务对其进行update或delete，但为什么要加GAP锁呢?

 

还是那句话，B+树的所有数据存储在叶子节点上，当有一个新的叫秦寿生的数据进来，一定是排在在这条id=34的数据前面或者后面的，我们如果对前后这个范围进行加锁了，那当然新的秦寿生就插不进来了。

 

那如果有一个新的范统要插进行呢？因为范统的前后并没有被锁住，是能成功插入的，这样就极大地提高了数据库的并发能力。
 

马失前蹄

上文中说了可重复读能防不可重复读，还能防幻读，它能防住所有的幻读吗？当然不是，也有马失前蹄的时候。

 

比如如下的例子:

1. a事务先select，b事务insert确实会加一个gap锁，但是如果b事务commit，这个gap锁就会释放（释放后a事务可以随意操作）

2. a事务再select出来的结果在MVCC下还和第一次select一样

3. 接着a事务不加条件地update，这个update会作用在所有行上（包括b事务新加的）

4. a事务再次select就会出现b事务中的新行，并且这个新行已经被update修改了。

 

Mysql官方给出的幻读解释是：只要在一个事务中，第二次select多出了row就算幻读，所以这个场景下，算出现幻读了。

原因就是：最后rr下，事务1第一次查询会有一份当前数据的快照，事务1update时，会拿到最新的快照，里面包含事务2的提交，并在此基础上进行更新。再次查询时会查询当前事务里最新的快照，就会出现这种情况。