摘要：事务这个词来自于英语中的transactional这个词的翻译，这个词的含义更多的是指 “交易”。在数据库系统或者软件系统中咱们一般 称 transactional 为事务html
本文分享自华为云社区《【数据库事务与锁机制】- 事务的隔离级别》，原文做者：技术火炬手 。mysql
事务这个词来自于英语中的transactional这个词的翻译，这个词的含义更多的是指 “交易”。在数据库系统或者软件系统中咱们一般 称 transactional 为事务。算法
数据库事务的四个特性 ACID：分别是 原子性、一致性、隔离性、持久性。数据库事务的这四大特性来源于 ISO标准的 ISO/IEC 10026-1:1992/COR 1:1996，它定义了事务须要具有以上四个特性。那么在InnoDB中是如何实现这些特征的呢？下面内容咱们讨论 MySQL （下指InnoDB引擎）对事务特性的支持是怎么实现的。sql
讨论MySQL的事务处理特性的实现原理以前咱们须要先了解下MySQL对MVCC的支持，关于MVCC 维基百科有以下解释。数据库
多版本并发控制(Multiversion concurrency control， MCC 或 MVCC)，是数据库管理系统经常使用的一种并发控制，也用于程序设计语言实现事务内存。MVCC意图解决读写锁形成的多个、长时间的读操做饿死写操做问题。每一个事务读到的数据项都是一个历史快照（snapshot)并依赖于实现的隔离级别。写操做不覆盖已有数据项，而是建立一个新的版本，直至所在操做提交时才变为可见。快照隔离使得事物看到它启动时的数据状态session
数据库事务的隔离级别
为了实现事务的隔离性，ISO 标准组织对事务锁须要实现的隔离级别有四种定义，下面咱们先对四种事务隔离的级别简单阐述一下。并发
READ UNCOMMITTED 读未提交
RU(READ UNCOMMITTED) 被称为读未提交，有些资料称之为浏览稳定（browse access）可是正确的翻译应该是未提交读。RU是最低标准的隔离，未提交读的意思就是在事务并发的状况下，能够允许一个事务在没有提交修改的的状况下被另一个事务读取到这个修改，这就就会产生脏读的状况。下面这个表格是各个事务隔离级别对于脏读、幻读、可重复读的抑制状况,事实上RU不但会产生脏读的状况并且其余两种读的状况都会发生。性能
首先咱们有必要澄清一下以上三种数据读问题的概念，对于数据库事务来讲咱们简单的认识是一系列的数据库操做在一个事务中，这个事务要不所有成功要不所有失败，可是要知道数据库在实际使用的过程当中不是串行的，它是并发的，串行场景下咱们事先事务就很是简单了，就是一个一个操做嘛，你们排队执行。可是在并发事务的场景下就会出现对同一个数据的竞争问题，简单的理解就是你也要读写这个数据，我也要读写这个数据，那么你们多个事务操做一个数据的时候怎么保证数据的一致和完整？这个时候就会出现数据的脏读、幻读、重复读问题。url
脏读
当一个事务容许读取另一个事务修改但未提交的数据时，就可能发生脏读（dirty reads）spa
脏读是指多个事务同时读写一个数据，当事务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是指锁定一个范围和数据自己，而不是只单单锁定数据自己，这样可以避免幻读的产生，官方文档
SERIALIZABLE 可串行化
是最高级别的事务隔离，按照定义是指全部事务都按照串行化进行执行，也就是没有并发事务的产生，这样就避免了全部读问题，可是这对于数据库来讲是不可能的，由于任何一个数据库都不能忍受这种状况，因此大多数人认为采用这种事务隔离级别会对性能产生很是大的影响，可是有些论文经过实验得出串行化并不会对性能产生太大的影响。
关于串行化是否是对性能产生影响，这取决于数据库对这种事务隔离级别的实现，不能彻底说串行就必定慢，反正我是不知道是否是真的对性能影响很大。
MySQL数据库事务隔离级别查询和修改
查询事务隔离级别
在MySQL中咱们能够经过如下方式查询数据库采用的事务隔离级别
show variables like '%tx_isolation%'; # 查询回话的事务隔离级别 SELECT @@session.tx_isolation; #查看全局的隔离级别 SELECT @@global.tx_isolation;
修改事务隔离级别
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);