MySQL数据库隔离级别及实现原理

最新推荐文章于 2024-08-21 19:00:00 发布

鉴均

最新推荐文章于 2024-08-21 19:00:00 发布

阅读量1.1k

点赞数 2

文章标签： MySQL隔离级别 MVCC 数据库锁原理

本文链接：https://blog.csdn.net/wowwilliam0/article/details/85271947

版权

本文深入探讨了MySQL数据库的隔离级别，包括READ_UNCOMMITTED、READ_COMMITTED、REPEATABLE_READ和SERIALIZABLE，重点解析了各级别的原理和应用场景。通过对锁机制、MVCC（多版本并发控制）的介绍，阐述了InnoDB如何处理一致性读和锁定读，以及悲观锁和乐观锁的概念。此外，详细分析了不同类型的锁，如记录锁、间隙锁和Next-Key Locks，以防止不可重复读和幻读问题。最后，通过示例展示了不同隔离级别下的行为差异，强调了在高并发场景下选择合适隔离级别的重要性。

摘要由CSDN通过智能技术生成

本篇博文为结合其它几篇博文而来，侵删。

所谓的数据库事务操作其实就是一组原子性的操作，要么全部操作成功，要么全部操作失败。

    并行事务的四大问题：
    1.更新丢失：和别的事务读到相同的东西，各自写，自己的写被覆盖了。（谁写的快谁的更新就丢失了）
    2.脏读：读到别的事务未提交的数据。（万一回滚，数据就是脏的无效的了）
    3.不可重复读：两次读之间有别的事务修改。
    4.幻读：两次读之间有别的事务增删。

    对应隔离级别
    1.READ UNCOMMITTED：读未提交，不处理。
    2.READ COMMITTED：读已提交，只读提交的数据，无脏读；
    3.REPEATABLE READ：可重复读，加行锁，两次读之间不会有修改，无脏读无重复读；
    4.SERIALIZABLE: 串行化，加表锁，全部串行，无所有问题。

    1.READ UNCIMMITTED（未提交读）
　　事务还没提交，而别的事务可以看到他其中修改的数据的后果，也就是脏读。

　　2.READ COMMITTED（提交读）
　　首先大多数数据库系统的默认隔离级别是READ COMMITTED，这种隔离级别就是一个事务的开始，只能看到已经完成的事务的结果，正在执行的，是无法被其他事务看到的。这种级别会出现读取旧数据的现象

　　3.REPEATABLE READ（可重复读）
 　 REPEATABLE READ解决了脏读的问题，该级别保证了每行的记录的结果是一致的，也就是上面说的读了旧数据的问题，但是却无法解决另一个问题，幻行，顾名思义就是突然蹦出来的行数据。指的就是某个事务在读取某个范围的数据，但是另一个事务又向这个范围的数据去插入数据，导致多次读取的时候，数据的行数不一致。

　　总结:虽然读取同一条数据可以保证一致性，但是却不能保证没有插入新的数据

　　4.SERIALIZABLE（可串行化）
　　SERIALIZABLE是最高的隔离级别，它通过强制事务串行执行（注意是串行），避免了前面的幻读情况，由于他大量加上锁，导致大量的请求超时，因此性能会比较低下，在需要数据一致性且并发量不需要那么大的时候才可能考虑这个隔离级别。

下面是各个隔离级别的原理：

READ_UNCOMMITED 的原理:

1，事务对当前被读取的数据不加锁；
2，事务在更新某数据的瞬间（就是发生更新的瞬间），必须先对其加 行级共享锁，直到事务结束才释放。

下面分别对应上面1，2产生的表现：

1，事务1读取某行记录时，事务2也能对这行记录进行读取、更新；当事务2对该记录进行更新时，事务1再次读取该记录，能读到事务2对该记录的修改版本，即使该修改尚未被提交。
2，事务1更新某行记录时，事务2不能对这行记录做更新，直到事务1结束。

READ_COMMITED 的原理:

1，事务对当前被读取的数据加 行级共享锁（当读到时才加锁），一旦读完该行，立即释放该行级共享锁；
2，事务在更新某数据的瞬间（就是发生更新的瞬间），必须先对其加 行级排他锁，直到事务结束才释放。

表现：

1，事务1读取某行记录时，事务2也能对这行记录进行读取、更新；当事务2对该记录进行更新时，事务1再次读取该记录，读到的只能是事务2对其更新前的版本，要不就是事务2提交后的版本。
2，事务1更新某行记录时，事务2不能对这行记录做更新，直到事务1结束。

REPEATABLE READ 的原理:

1，事务在读取某数据的瞬间（就是开始读取的瞬间），必须先对其加 行级共享锁，直到事务结束才释放；
2，事务在更新某数据的瞬间（就是发生更新的瞬间），必须先对其加 行级排他锁，直到事务结束才释放。

表现：

1，事务1读取某行记录时，事务2也能对这行记录进行读取、更新；当事务2对该记录进行更新时，事务1再次读取该记录，读到的仍然是第一次读取的那个版本。
2，事务1更新某行记录时，事务2不能对这行记录做更新，直到事务1结束。

SERIALIZABLE 的原理:

1，事务在读取数据时，必须先对其加 表级共享锁 ，直到事务结束才释放；
2，事务在更新数据时，必须先对其加 表级排他锁 ，直到事务结束才释放。

表现：

1，事务1正在读取A表中的记录时，则事务2也能读取A表，但不能对A表做更新、新增、删除，直到事务1结束。
2，事务1正在更新A表中的记录时，则事务2不能读取A表的任意记录，更不可能对A表做更新、新增、删除，直到事务1结束。

这里咋一看觉得能理解，但细想没有特别搞清，主要是这里面出现的几种锁，下面是数据库涉及和本文涉及到的锁的解释：
这里只针对MySQL，其他的可能有细微差别，但总体都是一个思想；
MySQL的锁机制比较简单，其最显著的特点是不同的存储引擎支持不同的锁机制。比如，

MyISAM和MEMORY存储引擎采用的是表级锁（table-level locking）。
InnoDB存储引擎既支持行级锁（row-level locking），也支持表级锁，但默认情况下是采用行级锁。
所有的锁都是绑定在数据库的索引机制上的！！！
首先锁可以分为：

表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高,并发度最低。
行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低,并发度也最高。
页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。

而除了粒度，锁根据模式分为：

共享锁(S)：发生在数据查找之前，多个事务的共享锁之间可以共存

排他锁(X)：发生在数据更新之前，排他锁是一个独占锁，与其他锁都不兼容

更新锁(U)：发生在更新语句中，更新锁用来查找数据，当查找的数据不是要更新的数据时转化为S锁，当是要更新的数据时转化为X锁

意向锁：发生在较低粒度级别的资源获取之前，表示对该资源下低粒度的资源添加对应的锁，意向锁有分为：意向共享锁(IS) ，意向排他锁(IX)，意向更新锁(IU)，共享意向排他锁(SIX)，共享意向更新锁(SIU)，更新意向排他锁(UIX)

意向锁又分为

意向共享锁（IS）：事务打算给数据行加行共享锁，事务在给一个数据行加共享锁前必须先取得该表的IS锁。
意向排他锁（IX）：事务打算给数据行加行排他锁，事务在给一个数据行加排他锁前必须先取得该表的IX锁。

共享锁／排他锁／更新锁一般作用在较低级别上，例如数据行或数据页，意向锁一般作用在较高的级别上，例如数据表或数据。锁是有层级结构的，若在数据行上持有排他锁的时候，则会在所在的数据页上持有意向排他锁. 在一个事务中，可能由于锁持有的时间太长或个数太多，出于节约资源的考虑，会造成锁升级；

我理解的就以最后一个SERIALIZABLE来说，开始时是设置的表级共享锁，分为表级别的而且是共享锁，表级别就是作用于整个表，不是行级别！而共享锁，则说明了其他事务也是共享锁的情况下可以共享这个表！虽然仅限于读，但这样也可能存在脏读等情况的存在，而如果换成表级排它锁，那么第一个事务在使用了这个锁之后，那其他事务连这个表的读的权限也没有，从根本上避免了各种可能的问题。

总结一下各个索引引擎的情况：

1.InnoDB（MySQL默认存储引擎 从版本5.5.5开始）
支持事务，行级锁，以及外键，拥有高并发处理能力。但是在创建索引和加载数据时，比MyISAM慢。默认的隔离级别是Repeatable Read（可重复读）

2.MyISAM
不支持事务和行级锁。所以速度很快，性能优秀。可以对整张表加锁，支持并发插入，支持全文索引。

3.MEMORY
支持Hash索引，内存表，Memory引擎将数据存储在内存中，表结构不是存储在内存中的，查询时不需要执行磁盘I/O操作，所以要比MyISAM和InnoDB快很多倍，但是数据库断电或是重启后，表中的数据将会丢失，表结构不会丢失。

MVCC的全称是“多版本并发控制”。这项技术使得InnoDB的事务隔离级别下执行一致性读操作有了保证，换言之，就是为了查询一些正在被另一个事务更新的行，并且可以看到它们被更新之前的值。这是一个可以用来增强并发性的强大的技术，因为这样的一来的话查询就不用等待另一个事务释放锁。这项技术在数据库领域并不是普遍使用的。一些其它的数据库产品，以及mysql其它的存储引擎并不支持它。

说明

网上看到大量的文章讲到MVCC都是说给没一行增加两个隐藏的字段分别表示行的创建时间以及过期时间，它们存储的并不是时间，而是事务版本号。

事实上，这种说法并不准确，严格的来讲，InnoDB会给数据库中的每一行增加三个字段，它们分别是DB_TRX_ID、DB_ROLL_PTR、DB_ROW_ID。

但是，为了理解的方便，我们可以这样去理解，索引接下来的讲解中也还是用这两个字段的方式去理解。

增删查改

在InnoDB中，给每行增加两个隐藏字段来实现MVCC，一个用来记录数据行的创建时间，另一个用来记录行的过期时间（删除时间）。在实际操作中，存储的并不是时间，而是事务的版本号，每开启一个新事务，事务的版本号就会递增。

于是乎，默认的隔离级别（REPEATABLE READ）下，增删查改变成了这样：

SELECT
- 读取创建版本小于或等于当前事务版本号，并且删除版本为空或大于当前事务版本号的记录。这样可以保证在读取之前记录是存在的。
INSERT
- 将当前事务的版本号保存至行的创建版本号
UPDATE
- 新插入一行，并以当前事务的版本号作为新行的创建版本号，同时将原记录行的删除版本号设置为当前事务版本号
DELETE
- 将当前事务的版本号保存至行的删除版本号

快照读和当前读

快照读：读取的是快照版本，也就是历史版本

当前读：读取的是最新版本

普通的SELECT就是快照读，而UPDATE、DELETE、INSERT、SELECT ... LOCK IN SHARE MODE、SELECT ... FOR UPDATE是当前读。

一致性非锁定读和锁定读

锁定读

　　在一个事务中，标准的SELECT语句是不会加锁，但是有两种情况例外。SELECT ... LOCK IN SHARE MODE 和 SELECT ... FOR UPDATE。

　　SELECT ... LOCK IN SHARE MODE

　　给记录假设共享锁，这样一来的话，其它事务只能读不能修改，直到当前事务提交

　　SELECT ... FOR UPDATE

　　给索引记录加锁，这种情况下跟UPDATE的加锁情况是一样的

一致性非锁定读

　　consistent read （一致性读），InnoDB用多版本来提供查询数据库在某个时间点的快照。如果隔离级别是REPEATABLE READ，那么在同一个事务中的所有一致性读都读的是事务中第一个这样的读读到的快照；如果是READ COMMITTED，那么一个事务中的每一个一致性读都会读到它自己刷新的快照版本。Consistent read（一致性读）是READ COMMITTED和REPEATABLE READ隔离级别下普通SELECT语句默认的模式。一致性读不会给它所访问的表加任何形式的锁，因此其它事务可以同时并发的修改它们。

悲观锁和乐观锁

悲观锁，正如它的名字那样，数据库总是认为别人会去修改它所要操作的数据，因此在数据库处理过程中将数据加锁。其实现依靠数据库底层。

乐观锁，如它的名字那样，总是认为别人不会去修改，只有在提交更新的时候去检查数据的状态。通常是给数据增加一个字段来标识数据的版本。

锁

有这样三种锁我们需要了解

Record Locks（记录锁）：在索引记录上加锁。
Gap Locks（间隙锁）：在索引记录之间加锁，或者在第一个索引记录之前加锁，或者在最后一个索引记录之后加锁。
Next-Key Locks：在索引记录上加锁，并且在索引记录之前的间隙加锁。它相当于是Record Locks与Gap Locks的一个结合。

假设一个索引包含以下几个值：10,11,13,20。那么这个索引的next-key锁将会覆盖以下区间：

(negative infinity, 10]
(10, 11]
(11, 13]
(13, 20]
(20, positive infinity)

了解了以上概念之后，接下来具体就简单分析下REPEATABLE READ隔离级别是如何实现的

理论分析

之所以说是理论分析，是因为要是实际操作证明的话我也不知道怎么去证明，毕竟作者水平实在有限。

但是，这并不意味着我在此胡说八道，有官方文档为证。

这段话的大致意思是，在默认的隔离级别中，普通的SELECT用的是一致性读不加锁。而对于锁定读、UPDATE和DELETE，则需要加锁，至于加什么锁视情况而定。如果你对一个唯一索引使用了唯一的检索条件，那么只需锁定索引记录即可；如果你没有使用唯一索引作为检索条件，或者用到了索引范围扫描，那么将会使用间隙锁或者next-key锁以此来阻塞其它会话向这个范围内的间隙插入数据。

作者曾经有一个误区，认为按照前面说MVCC下的增删查改的行为就不会出现任何问题，也不会出现不可重复读和幻读。但其实是大错特错。

举个很简单的例子，假设事务A更新表中id=1的记录，而事务B也更新这条记录，并且B先提交，如果按照前面MVVC说的，事务A读取id=1的快照版本，那么它看不到B所提交的修改，此时如果直接更新的话就会覆盖B之前的修改，这就不对了，可能B和A修改的不是一个字段，但是这样一来，B的修改就丢失了，这是不允许的。

所以，在修改的时候一定不是快照读，而是当前读。

而且，前面也讲过只有普通的SELECT才是快照读，其它诸如UPDATE、删除都是当前读。修改的时候加锁这是必然的，同时为了防止幻读的出现还需要加间隙锁。