MySQL事务处理特性的实现原理

Love The Way You Lie 2022-10-09 12:13 165阅读 0赞

事务这个词来自于英语中的transactional这个词的翻译，这个词的含义更多的是指 “交易”。在数据库系统或者软件系统中我们通常 称 transactional 为事务。

数据库事务的四个特性 ACID：分别是 原子性、一致性、隔离性、持久性。数据库事务的这四大特性来源于 ISO标准的 ISO/IEC 10026-1:1992/COR 1:1996，它定义了事务需要具备以上四个特性。那么在InnoDB中是如何实现这些特征的呢？下面内容我们讨论 MySQL （下指InnoDB引擎）对事务特性的支持是怎么实现的。

讨论MySQL的事务处理特性的实现原理之前我们需要先了解下MySQL对MVCC的支持，关于MVCC 维基百科有如下解释。

多版本并发控制(Multiversion concurrency control， MCC 或 MVCC)，是数据库管理系统常用的一种并发控制，也用于程序设计语言实现事务内存。MVCC意图解决读写锁造成的多个、长时间的读操作饿死写操作问题。每个事务读到的数据项都是一个历史快照（snapshot)并依赖于实现的隔离级别。写操作不覆盖已有数据项，而是创建一个新的版本，直至所在操作提交时才变为可见。快照隔离使得事物看到它启动时的数据状态

### **数据库事务的隔离级别** ###

为了实现事务的隔离性，ISO 标准组织对事务锁需要实现的隔离级别有四种定义(如下图），下面我们先对四种事务隔离的级别简单阐述一下。

![MySQL事务处理,MySQL事务处理特性,数据库事务的隔离级别][MySQL_MySQL]

**READ UNCOMMITTED 读未提交**

RU(READ UNCOMMITTED) 被称为读未提交，有些资料称之为浏览稳定（browse access）但是正确的翻译应该是未提交读。RU是最低标准的隔离，未提交读的意思就是在事务并发的情况下，可以容许一个事务在没有提交修改的的情况下被另外一个事务读取到这个修改，这就就会产生脏读的情况。下面这个表格是各个事务隔离级别对于脏读、幻读、可重复读的抑制情况,事实上RU不但会产生脏读的情况而且其他两种读的情况都会发生。

首先我们有必要澄清一下以上三种数据读问题的概念，对于数据库事务来说我们简单的认识是一系列的数据库操作在一个事务中，这个事务要不全部成功要不全部失败，但是要知道数据库在实际使用的过程中不是串行的，它是并发的，串行场景下我们事先事务就非常简单了，就是一个一个操作嘛，大家排队执行。但是在并发事务的场景下就会出现对同一个数据的竞争问题，简单的理解就是你也要读写这个数据，我也要读写这个数据，那么大家多个事务操作一个数据的时候怎么保证数据的一致和完整？这个时候就会出现数据的脏读、幻读、重复读问题。

**脏读**

当一个事务允许读取另外一个事务修改但未提交的数据时，就可能发生脏读（dirty reads）

脏读是指多个事务同时读写一个数据，当事务1中修改和读取数据A时，事务2对数据A做了修改，然后这个修改反映到了事务A中。

我们试想有这样的场景，假如两个事务都在操作金额表中的同一条记录，事务A需要获得到当前金额值然后给他做加3的操作（用于买黄瓜）,原来这个金额的值是5,但是此时事务B将这条数据的金额修改成了8，然后这个修改被事务A拿到然后在8的基础上加了3等于11。但是万万没想到在A事务做完这个操作以后B事务回滚了（反悔了，香蕉的钱没给）。这个时候A事务完成以后账户的金额莫名其妙的变成了11，但是事实上应该是8。这也就是脏读的情况。

**不可重复读**

在一次事务中，当一行数据获取两遍得到不同的结果表示发生了不可重复读（non-repeatable reads）

在理解不可重复读之前先理解什么是可重复读，可重复读的意思就是在一个事务中对同一个数据的多次读取其结果应该是相同的（在这个事务中没有修改它的值）。那么反过来的意思就是在一个事务中对一个数据的多次读取的值是不一样的，什么情况下会出现不可重复读呢？

还是上面的例子，假如事务A在做加3操作之前先读取了原来的值也就是5，然后继续其他操作，这个时候事务B对这条记录进行了加3的操作然后提交了，当事务A再次读这个值的时候发现当前值变成了8，这个时候前后两次的值完全不一样，这也就是不可重复读。

不可重复读是针对单个事务来说的，也就是在一个事务中是否可以对一条数据做重复的读取，如果不能，那么也就意味着不满足可重复读的要求。

不可重复读和脏读非常类似，但是两者是有区别的脏读是指事务2没有提交这个修改就被事务1获取到了修改后的值，而不可重复读是指提交了修改以后产生了不一致的情况。

**幻读**

在事务执行过程中，当两个完全相同的查询语句执行得到不同的结果集。这种现象称为幻读（phantom read）

幻读实际上是不可重读的一种场景，比如在事务1中，第一次按照某个条件读取到了3条数据，但是此时事务2在这个表中添加了一条满足此条件的数据，在事务1第二次读的时候发现多了一条数据（反过来就是少了一条数据）,这时候对于事务1来说就有点莫名其妙了，貌似产生了幻觉（发多货了），所以称之为幻读。

所以针对未提交读这种隔离级别，这三种读问题都有可能产生，所以它是级别最低的事务隔离。

**READ COMMITTED 读提交**

RC(READ COMMITTED) 读提交是指在提交以后可以读，有些资料称之为提交读（国内翻译也是醉了）。提交读主要针对的场景是UPDATE语句，就是针对更新只有提交了以后才能读，试想一下在上面介绍脏读的时候，如果事务2在修改完金额以后提交了这个值而不是回滚，那么久没有脏读的情况。

这也就是为什么提交读只能解决脏读的问题而不能解决其他两种读的问题。因为很显然就算事务2提交了这次修改，那么对于事务1来说前后两次的读取都是不一致的（不可重复读），当然幻读的场景更是存在了，因为幻读本来就是不可重复读的特殊场景。

**REPEATABLE READS 可重复读**

RR(REPEATABLE READS)可重复读是仅次于SERIALIZABLE（串行化）的一种事务隔离级别，通常可重复读是通过锁实现的，它避免不了幻读的产生。在InnoDB中默认采用RR这种事务隔离级别，但是和其他数据库不同的是InnoDB在在RR的事务隔离级别下采用了NKL的锁算法（Next-Key Lock），避免了幻读的产生。这与其他数据库不同，所以在InnoDB中RR的事务隔离级别达到了串行化的事务隔离标准。

NKL是指锁定一个范围和数据本身，而不是只单单锁定数据本身，这样能够避免幻读的产生，[官方文档][Link 1]

**SERIALIZABLE 可串行化**

是最高级别的事务隔离，按照定义是指所有事务都按照串行化进行执行，也就是没有并发事务的产生，这样就避免了所有读问题，但是这对于数据库来说是不可能的，因为任何一个数据库都不能忍受这种情况，所以大多数人认为采用这种事务隔离级别会对性能产生非常大的影响，但是有些论文通过实验得出串行化并不会对性能产生太大的影响。

关于串行化是不是对性能产生影响，这取决于数据库对这种事务隔离级别的实现，不能完全说串行就一定慢，反正我是不知道是不是真的对性能影响很大。

### **MySQL数据库事务隔离级别查询和修改** ###

**查询事务隔离级别**

在MySQL中我们可以通过以下方式查询数据库采用的事务隔离级别

show variables like '%tx_isolation%';
     # 查询回话的事务隔离级别
    SELECT @@session.tx_isolation;
    #查看全局的隔离级别
    SELECT @@global.tx_isolation;

![MySQL事务处理,MySQL事务处理特性,数据库事务的隔离级别][MySQL_MySQL 1]

**修改事务隔离级别**

MySQL 提供了 SET TRANSACTION 语句，该语句可以改变单个会话或全局的事务隔离级别。语法格式如下：

SET [SESSION | GLOBAL] TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE}

其中，SESSION 和 GLOBAL 关键字用来指定修改的事务隔离级别的范围

*  SESSION：表示修改的事务隔离级别将应用于当前 session（当前 cmd 窗口）内的所有事务；
 *  GLOBAL：表示修改的事务隔离级别将应用于所有 session（全局）中的所有事务，且当前已经存在的 session 不受影响；

如果省略 SESSION 和 GLOBAL，表示修改的事务隔离级别将应用于当前 session 内的下一个还未开始的事务。

任何用户都能改变会话的事务隔离级别，但是只有拥有 SUPER 权限的用户才能改变全局的事务隔离级别

**JDBC 修改当前连接的隔离级别**

connection.setTransactionIsolation(Connection.TRANSACTION_READ_UNCOMMITTED);

了解更多数据库知识，点击全文链接：[www.shulanxt.com/doc/mysqldoc/swclb][www.shulanxt.com_doc_mysqldoc_swclb]

[MySQL_MySQL]: /images/20221005/b844614179e7402db08878c343961f98.png
[Link 1]: https://www.oschina.net/action/GoToLink?url=https%3A%2F%2Fdev.mysql.com%2Fdoc%2Frefman%2F8.0%2Fen%2Finnodb-locking.html
[MySQL_MySQL 1]: /images/20221005/743a8d7f98d24f7b8eaeec63a6a7e2fd.png
[www.shulanxt.com_doc_mysqldoc_swclb]: https://www.shulanxt.com/doc/mysqldoc/swclb