一、什么是事务

一个最小的不可再分的工作单元；通常一个事务对应一个完整的业务(例如银行账户转账业务，该业务就是一个最小的工作单元)。一个完整的业务需要批量的DML(insert、update、delete)语句共同联合完成。

• 在 MySQL 中只有使用了 Innodb 数据库引擎的数据库或表才支持事务。
• 事务处理可以用来维护数据库的完整性，保证成批的 SQL 语句要么全部执行，要么全部不执行。
• 事务用来管理 insert,update,delete 语句。

二、事务的基本要素（ACID）

• 原子性（Atomicity）：事务开始后所有操作，要么全部做完，要么全部不做，不可能停滞在中间环节。事务执行过程中出错，会回滚到事务开始前的状态，所有的操作就像没有发生一样。也就是说事务是一个不可分割的整体，就像化学中学过的原子，是物质构成的基本单位。

• 一致性（Consistency）：事务开始前和结束后，数据库的完整性约束没有被破坏 。比如A向B转账，不可能A扣了钱，B却没收到。

• 隔离性（Isolation）：同一时间，只允许一个事务请求同一数据，不同的事务之间彼此没有任何干扰。比如A正在从一张银行卡中取钱，在A取钱的过程结束前，B不能向这张卡转账。

• 持久性（Durability）：事务完成后，事务对数据库的所有更新将被保存到数据库，不能回滚。

三、事务的四种隔离级别

SQL标准定义了4类隔离级别，包括了一些具体规则，用来限定事务内外的哪些改变是可见的，哪些是不可见的。低级别的隔离级一般支持更高的并发处理，并拥有更低的系统开销。

Read Uncommitted（读未提交）： 在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用，因为它的性能也不比其他级别好多少。

Read Committed（不可重复读）： 这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这种隔离级别也支持所谓的不可重复读（Nonrepeatable Read），因为同一事务的其他实例在该实例处理其间可能会有新的commit，所以同一select可能返回不同结果。

Repeatable Read（可重复读）： 这是MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行。不过理论上，这会导致另一个棘手的问题：幻读 （Phantom Read）。简单的说，幻读指当用户读取某一范围的数据行时，另一个事务又在该范围内插入了新行，当用户再读取该范围的数据行时，会发现有新的“幻影” 行。InnoDB和Falcon存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）机制解决了该问题。

Serializable（串行化）： 这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。简言之，它是在每个读的数据行上加上共享锁。在这个级别，可能导致大量的超时现象和锁竞争。

这四种隔离级别采取不同的锁类型来实现，若读取的是同一个数据的话，就容易发生问题。例如：

• 脏读(Drity Read)： 某个事务已更新一份数据，另一个事务在此时读取了同一份数据，由于某些原因，前一个RollBack了操作，则后一个事务所读取的数据就会是不正确的。
• 不可重复读(Non-repeatable read)： 在一个事务的两次查询之中数据不一致，这可能是两次查询过程中间插入了一个事务更新的原有的数据。
• 幻读(Phantom Read)： 在一个事务的两次查询中数据总数不一致，例如有一个事务查询了几列(Row)数据，而另一个事务却在此时插入了新的几列数据，先前的事务在接下来的查询中，就会发现有几列数据是它先前所没有的。

  注意： 不可重复读的和幻读很容易混淆，不可重复读侧重于修改，幻读侧重于新增或删除。

在MySQL中，实现了这四种隔离级别，分别有可能产生问题如下所示：

设置隔离级别:

set session transaction isolation level 隔离级别；例：set session transaction isolation level read uncommitted； #设置隔离级别start transaction; #开启事务select * from account;...commit;#提交事务

四、事务的并发问题及解决办法

因为MySQL默认事务隔离级别就是 可重复读（repeatable-read）， 所以对于 脏读 、不可重复读 MySQL已经解决了，现在可能遇到的问题就是 幻读，MySQL通过多版本并发控制（MVCC）机制解决了该问题。

1、什么是MVCC机制

MVCC（Multi-Version Concurrency Control）：多版本并发控制，是一种并发控制的方法，一般在数据库管理系统中，实现对数据库的并发访问，在编程语言中实现事务内存。

MVCC 在 MySQL InnoDB 中的实现主要是为了提高数据库并发性能，用更好的方式去处理读-写冲突，做到即使有读写冲突时，也能做到不加锁，非阻塞并发读。

• 数据库并发场景一般有三种：
  • 读-读：不存在任何问题，不需要并发控制
  • 读-写：有线程安全问题，可能会造成事务隔离性问题，可能会有脏读，幻读，不可重复读
  • 写-写：有线程安全问题，可能会存在更新丢失问题。

MVCC实现原理

InnoDB 实现MVCC是通过 Read View与 Undo Log 实现的，Undo Log 保存了历史快照，形成 版本链，Read View 可见性规则判断当前版本的数据是否可见。

• InnnoDB执行查询语句的具体步骤为：
  • 执行语句之前获取查询事务自己的事务Id，即事务版本号；
  • 通过事务id获取Read View；
  • 查询存储的数据，将其事务Id与Read View中的事务版本号进行比较；
  • 不符合Read View的可见性规则，则读取Undo log中历史快照数据；
  • 找到当前事务能够读取的数据返回。

而在实际的使用过程中，Read View 在不同的隔离级别下是得工作方式是不一样。关于MVCC这里不做更多的描述了，想了解可以看看这篇博客 MySQL(八)：读懂MVCC多版本并发控制。

除了上面所说的 Read View、 Undo Log 、版本链，MVCC的实现还依赖于 快照读和当前读、隐式字段。而在 快照读 的情况下可以解决幻读问题，但是在 当前读 的情况下是需要配合锁来解决幻读。
【隐式字段】【undo日志】【版本链】【快照读和当前读】【读视图】。

快照读： 也叫 普通读，读取的是记录数据的可见版本，不加锁，不加锁的普通select语句都是快照读，即不加锁的非阻塞读。快照读的执行方式是生成 ReadView，直接利用 MVCC 机制来进行读取，并不会对记录进行加锁。

当前读： 也称 锁定读，读取的是记录数据的最新版本，并且需要先获取对应记录的锁。

2、快照读的幻读问题

通过mvcc可解决幻读。

当前 user表 数据：

开始事务：

假设表中有1、2、3三条数据，以及有两个事务A/B，A读取数据，B插入数据，由于采用的是【快照读】的方式，在A事务开启时会产生一个【版本快照a】，然后通过MVCC的 Read View 对版本快照中各个版本链中的数据进行可见性判断，读取相应的版本快照a，两次查询结果都是【id=2，3】两条数据。

3、当前读的幻读问题

事务A在执行当前读【select … lock in share mode】的时候，在查询结果上加了 共享锁，并且在【id > 4】这个范围上也加了 间隙锁 ，所以上图中的事务B执行插入操作时被阻塞了。所以事务A两次读取的数据是一样的。因此，在这种情况下是不会存在幻读问题。

还有一种在当前读情况下不能解决幻读问题：

遇到这种情况可使用 串行化读 的隔离级别。

4、总结

在快照读情况下，mysql通过mvcc来避免幻读。
在当前读情况下，mysql通过 共享锁或排他锁 和 间隙锁来避免其他事务修改:

• 1.使用串行化读的隔离级别。
• 2.(update、delete)当where条件为主键时，通过对主键索引加record locks(索引加锁/行锁)处理幻读。
• 3.(update、delete)当where条件为非主键索引时，通过next-key锁处理。next-key是record locks(索引加锁/行锁) 和 gap locks(间隙锁，每次锁住的不光是需要使用的数据，还会锁住这些数据附近的数据)的结合。

一些具体的示例参考下面「星河之码」的原创文章，里面讲的比较详细示例底层实现都讲的比较清楚。
MySQL(八)：读懂MVCC多版本并发控制
MySQL(九)：MVCC能否解决幻读问题