Mysql之事务篇

1、事务

数据库事务（简称:事务）是数据库管理系统执行过程中的一个逻辑单位，由一个有限的数据库操作序列构成。事务的使用是数据库管理系统区别文件系统的重要特征之一。

事务拥有四个重要的特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability），人们习惯称之为 ACID 特性。下面我逐一对其进行解释。

原子性（Atomicity）

事务开始后所有操作，要么全部做完，要么全部不做，不可能停滞在中间环节。事务执行过程中出错，会回滚到事务开始前的状态，所有的操作就像没有发生一样。

注：Mysql 通过 undo log 来保证原子性。

一致性（Consistency）

指事务将数据库从一种状态转变为另一种一致的的状态。事务开始前和结束后，数据库的完整性约束没有被破坏。

注：Mysql 数据层面一致性通过AID三特性来保证。即ACID四大特性中，C是目的，A、I、D都是手段，是为了保证一致性，数据库提供的手段。

隔离性（Isolation）

要求每个读写事务的对象对其他事务的操作对象能互相分离，即该事务提交前对其他事务不可见。也可以理解为多个事务并发访问时，事务之间是隔离的，一个事务不应该影响其它事务运行效果。这指的是在并发环境中，当不同的事务同时操纵相同的数据时，每个事务都有各自的完整数据空间。由并发事务所做的修改必须与任何其他并发事务所做的修改隔离。例如一个用户在更新自己的个人信息的同时，是不能看到系统管理员也在更新该用户的个人信息（此时更新事务还未提交）。

注：Mysql 通过锁机制和MVCC机制来保证事务的隔离性。

持久性（Durability）

事务一旦提交，则其结果就是永久性的。即使发生宕机的故障，数据库也能将数据恢复，也就是说事务完成后，事务对数据库的所有更新将被保存到数据库，不能回滚。这只是从事务本身的角度来保证，排除 RDBMS（关系型数据库管理系统，例如 Oracle、Mysql 等）本身发生的故障。

注：Mysql 使用 redo log 来保证事务的持久性。

2、事务并发带来的问题

在典型的应用程序中，多个事务并发运行，经常会操作相同的数据来完成各自的任务（多个用户对同一数据进行操作）。并发虽然是必须的，但可能会导致以下的问题。

脏读（Dirty read）: 当一个事务正在访问数据并且对数据进行了修改，而这种修改还没有提交到数据库中，这时另外一个事务也访问了这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据，那么另外一个事务读到的这个数据是“脏数据”，依据“脏数据”所做的操作可能是不正确的。

丢失修改（Lost to modify）: 指在一个事务读取一个数据时，另外一个事务也访问了该数据，那么在第一个事务中修改了这个数据后，第二个事务也修改了这个数据。这样第一个事务内的修改结果就被丢失，因此称为丢失修。例如：事务1读取某表中的数据A=20，事务2也读取A=20，事务1修改A=A-1，事务2也修改A=A-1，最终结果A=19，事务1的修改被丢失。

不可重复读（Unrepeatableread）: 指在一个事务内多次读同一数据。在这个事务还没有结束时，另一个事务也访问该数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改导致第一个事务两次读取的数据可能不太一样。这就发生了在一个事务内两次读到的数据是不一样的情况，因此称为不可重复读。

幻读（Phantom read）: 幻读与不可重复读类似。它发生在一个事务（T1）读取了几行数据，接着另一个并发事务（T2）插入了一些数据时。在随后的查询中，第一个事务（T1）就会发现多了一些原本不存在的记录，就好像发生了幻觉一样，所以称为幻读。

不可重复读和幻读区别：

不可重复读的重点是修改比如多次读取一条记录发现其中某些列的值被修改，幻读的重点在于新增或者删除比如多次读取一条记录发现记录增多或减少了。

3、事务隔离级别有哪些？

为了解决事务并发带来的问题，数据库设置了不同的隔离级别来解决相应的读写影响。

SQL 标准定义了四个隔离级别：

1. READ-UNCOMMITTED(读取未提交)： 最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读。
2. READ-COMMITTED(读取已提交)： 允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生。
3. REPEATABLE-READ(可重复读)： 对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生。
4. SERIALIZABLE(可串行化)： 最高的隔离级别，完全服从ACID的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。

需要注意的是，这是标准事务隔离级别下的定义。在innodb存储引擎中，在可重复读隔离级别下，解决了幻读的问题。

4、事务ACID特性实现原理

4.1、事务的原子性实现原理

    实现原子性的关键，是当事务回滚时能够撤销所有已经成功执行的sql语句。InnoDB实现回滚，靠的是undo log：当事务对数据库进行修改时，InnoDB会生成对应的undo log；如果事务执行失败或调用了rollback，导致事务需要回滚，便可以利用undo log中的信息将数据回滚到修改之前的样子。

    undo log还要另外一个重要作用，就是用于mvcc中，进行多版本控制，也就是实现事务隔离性的基础，当用户读取一行记录时，如果这个记录已接被其他事务占用，那么当前事务就可以通过undo读取之前的行版本信息，用来实现非锁定读取，就是“快照读”。

4.2、事务的隔离性实现原理

事务的隔离性通过 锁 和 MVCC 来解决。主要可以分为两个方面：

4.2.1、行锁

InnoDB中，实现了两种标准的行级锁：

• 共享锁（S Lock），也叫读锁，允许事务读取一行数据。
• 排它锁（X Lock），也叫写锁，允许事务删除或者更新一行数据（注意，这里没有提到插入哦，插入涉及到幻读，可以看文章最后的说明）

普通select语句不会有任何锁，那么如何获得共享锁和排它锁呢？

• Select … lock in share mode语句能够获得共享锁
• Select … for update（特殊的select，用mysql简单实现分布式锁经常用它）、Update、delete语句能够获得排它锁

当一个事务A已经获得了行r的共享锁，那么另一个事务B可以立刻获得行r的共享锁，因为不会改变r的数值，这种叫做锁兼容。

如果这时候有事务C希望获得行r的排它锁，那么就必须等待事务A和事务B释放行r的共享锁之后，才能获得排它锁，这种叫做锁不兼容。

普通的select不会对行上锁，而select…lock in share mode会上共享锁，select…for update会上排它锁。

• 对于普通的select的读取方式，称为”快照读“，也叫”一致性非锁定读“。
• 对于带锁的select读取，或者update tb set a = a+1（读取a的当前值），称为“当前读”，也叫“一致性锁定读”。

如果在update、insert的时候，不能进行select，那么服务的并发访问性能就太差了。因此，我们日常的查询，都是“快照读”，不会上锁，只有在update\insert\“当前读”的时候，才会上锁。而为了解决“快照读”的并发访问问题，就引入了MVCC。

4.2.2、MVCC

MVCC即多版本并发控制，所谓多版本是指一行记录在数据库中存储了多个版本，每个版本以事务ID作为版本号。在每个记录多版本的基础上，需要利用“一致性视图”来做版本的可见性判断。

一致性视图定义了在事务期间，能看到那些版本的数据。

1. 视图主要解决innodb在读提交和可重复读级别的并发访问问题。

1. “读未提及”级别下，没有一致性视图
2. “读已提交”级别下，会在 每个SQL开始执行的时候 创建一致性视图
3. “可重复读”级别下，会在 每个事务开始的时候 创建一致性视图
4. “串行化”级别下，直接通过加锁避免并发问题
5. 创建视图逻辑

1. 当一个事务开启的时候，会向系统申请一个新事务id
2. 此时，可能还有多个正在进行的其他事务没有提交，因此在瞬时时刻，是有多个活跃的未提交事务id
3. 将这些未提交的事务id组成一个数组，数组里面最小的事务id记录为低水位，当前系统创建过的事务id的最大值+1记录为高水位
4. 这个数组array 和 高水位，就组成了“一致性视图”。
5. 可见性判断规则

• 如果版本号小于“低水位”，说明事务已经提交，那肯定 可见；
• 如果版本号大于“高水位”，说明这行数据的这个事务id版本是在快照后产生的，那肯定 不可见；
• 如果版本号在事务数组array中，说明这个事务还没提交，所以 不可见；
• 如果版本号不在事务数组array中，且低于高水位，说明这个事务已经提交，所以 可见；
• 当然，无论什么时候，自己的事务id中的任何变化，都是可见的

4.3、事务的一致性实现原理

        从数据库层面，数据库通过原子性、隔离性、持久性来保证一致性。也就是说ACID四大特性之中，C(一致性)是目的，A(原子性)、I(隔离性)、D(持久性)是手段，是为了保证一致性，数据库提供的手段。数据库必须要实现AID三大特性，才有可能实现一致性。例如，原子性无法保证，显然一致性也无法保证。

从应用层面，通过代码判断数据库数据是否有效，然后决定回滚还是提交数据！

4.4、事务的持久性实现原理

redo log是实现事务持久性的关键，是InnoDB特有的日志。

InnoDB作为MySQL的存储引擎，数据是存放在磁盘中的，但如果每次读写数据都需要磁盘IO，效率会很低。

为此，InnoDB提供了缓存(Buffer Pool)，Buffer Pool中包含了磁盘中部分数据页的映射，作为访问数据库的缓冲：当从数据库读取数据时，会首先从Buffer Pool中读取，如果Buffer Pool中没有，则从磁盘读取后放入Buffer Pool；

当向数据库写入数据时，会首先写入Buffer Pool，Buffer Pool中修改的数据会定期刷新到磁盘中（这一过程称为刷脏）。

Buffer Pool的使用大大提高了读写数据的效率，但是也带了新的问题：
如果MySQL宕机，而此时Buffer Pool中修改的数据还没有刷新到磁盘，就会导致数据的丢失，事务的持久性无法保证。

于是，redo log被引入来解决这个问题：

1. 当数据修改时，除了修改Buffer Pool中的数据，还会在redo log记录这次操作；
2. 当事务提交时，会调用fsync接口对redo log进行刷盘。如果MySQL宕机，重启时可以读取redo log中的数据，对数据库进行恢复。redo log采用的是WAL（Write-ahead logging，预写式日志），所有修改先写入日志，再更新到Buffer Pool，保证了数据不会因MySQL宕机而丢失，从而满足了持久性要求。

既然redo log也需要在事务提交时将日志写入磁盘，为什么它比直接将Buffer Pool中修改的数据写入磁盘(即刷脏)要快呢？

主要有以下两方面的原因：

1. 刷脏是随机IO，因为每次修改的数据位置随机，但写redo log是追加操作，属于顺序IO。
2. 刷脏是以数据页（Page）为单位的，MySQL默认页大小是16KB，一个Page上一个小修改都要整页写入；而redo log中只包含真正需要写入的部分，无效IO大大减少。