MySQL数据库之事务

一、概述

事务机制主要用于实现数据库对并发访问的支持和在并发访问下的数据一致性和可靠性（当多个用户访问同一份数据，一个用户更改该事物时可能会有其他用户同时发起更改请求，为保证数据库记录的更新从一个一致性状态转为另外一个一致性状态，使用事务是非常有必要的。）。MySQL的myisam存储引擎是不支持事务的，通过表锁来实现数据的可靠性，类似于Java多线程的同步锁synchronized，避免并发修改，但是并发性能较差，比较适合OLAP的应用，同时数据库奔溃恢复比较麻烦。
innodb存储引擎是支持事务的，支持多个客户端高性能地进行并发操作，相对myisam并发性能较好，比较适合OLTP的应用。innodb存储引擎实现了事务的ACID特性，即原子性，一致性，隔离性和持久性。
ACID（事务处理机制）特性主要用于保证并发访问时，数据的一致性和可靠性，是对简单地进行加表锁实现串行化访问来保证数据一致性和可靠性的一种改进和优化，实现了多个客户端的并发访问。

二、ACID实现

1. SQL标准的ACID的定义：

A：原子性，一次数据库访问包含的多个数据库操作是一个整体，要么全部成功执行，要么全部失败回滚，相当于一个原子操作，不允许部分成功，部分失败；
C：一致性，事务执行前后，数据保持一致状态，不存在数据不一致问题；
I：隔离性，或者称为并发性，实现多个客户端的并发事务操作相互隔离，互不影响。不过这个在数据库实现当中，影响程度一般需要和并发性取一个折中，即定义了多个隔离级别，每个隔离级别的隔离程度和并发性存在差异，具体后面分析。
D：只要事务成功提交，则数据保证持久化保存，即使数据库奔溃也能恢复回来，保证数据的可靠性。

2. Innodb的ACID实现
innodb存储引擎的原子性A和持久性D主要是通过redo重做日志来实现的，数据一致性除了redo日志外，需要undo日志来辅助实现，即当事务提交失败时，通过undo日志来实现回滚，取消该事务对数据库的操作。隔离性I主要是通过锁和MVCC机制来实现。

a. redo日志（重做日志）：原子性、持久性

事务在执行时需要将执行的事务日志写入到日志文件里，对应的日志文件为重做日志。当sql进行数据库更新操作时，首先将重做日志写入到日志缓冲区，客户端执行commit命令提交时，日志缓冲区的内容会被刷新到磁盘，日志缓冲区的刷新方式或者时间间隔可以通过参数innodb_flush_log_at_trx_commit控制。
redo日志主要是记录对数据的物理修改，在事务提交时，必须先将本次事务的所有修改写到redo日志中进行持久化，实现了原子性和持久性。redo日志写入成功之后才进行实际的事务提交，对数据库的数据进行实际的修改。
所以redo日志记录了所有的数据修改操作，如果在事务提交时写入redo日志成功，再进行数据库修改时，数据库发送了崩溃，则可以在重启时，通过redo日志来恢复这些修改。如果事务提交之前，数据库奔溃，则该次事务操作的所有修改都没有执行，保证了原子性。

b. undo（回滚）日志：一致性

与REDO日志相反，UNDO日志主要用于事务异常时的数据回滚，具体是复制食物前的数据库内容到UNDO缓冲区，在合适的时间将内容刷新到磁盘。UNDO日志均放在表空间.ibd数据文件中。
相对于redo日志记录数据的物理修改，undo日志是逻辑记录，是MySQL数据库内部的特殊的segment，segment内部对应每个事务都有一条记录，这个记录记录了该事务所有修改操作的逆过程。
在事务操作过程中，每个修改操作都会记录在undo日志中，记录到undo日志的内容与该次修改操作相反，如INSERT对应DELETE，UPDATE则对应更新前的记录（这里记录了该数据的数据快照，负责实现了MVCC机制）。
所以当该事务需要回滚时，只需要执行该事务对应的undo日志中的记录，即逆向的SQL语句，如插入了10条记录，则删除这10条记录。
对于undo日志的删除，不是事务提交后就马上删除的，而是通过purge线程来完成的。由于MVCC机制是基于undo日志来实现，故该事务对应的数据行的快照数据可能被其他事务在引用，所以通过purge线程来检测是否存在其他事务在引用该数据行的快照，如果没有才进行该事务对应的undo日志的删除。

c. 锁：隔离性

事务的隔离性主要是针对写操作，因为读操作是不会对数据进行修改，故不存在隔离的说法，通过隔离多个对相同的数据进行并发修改的事务，保证数据的一致性。
对于数据的修改操作一般需要加互斥锁（记为X锁），如果一个事务对数据进行了加X锁，则其他需要修改该数据的事务就需要阻塞等待该事务释放该X锁才能继续执行，所以加锁操作直接影响了并发性能。基于并发性和数据一致性的考虑，隔离性定义了READ-UNCOMMITTED，READ-COMMITTED，REPEATABLE-READ, SERIALIZABLE这四个隔离级别，并发性能依次变差，数据一致性依次变强。

三、隔离性

以上分析了事务的隔离性主要是通过锁和MVCC机制来实现，而隔离性主要是解决并发事务操作存在的以下问题，并通过事务隔离机制来规避这些问题，不过不是所有的隔离级别都会解决所有的这些问题，因为还需要与并发性取一个折中。

1. 事务（并发操作）存在的问题

a. 脏读

事务A读取了事务B已经修改但尚未提交的数据。若事务B回滚数据，事务A的数据存在不一致性的问题。

b. 幻读

事务A根据相同条件第二次查询到事务B提交的新增数据，两次数据结果集不一致。不符合事务的隔离性。

c. 不可重复读

事务A第一次读取最初数据，第二次读取事务B已经提交的修改或删除数据。导致两次读取数据不一致。不符合事务的隔离性。

d. 更新丢失

数据覆盖：一个事务覆盖了另外一个事务的执行结果；
数据脏读：一个事务基于另外一个未提交事务的数据修改来做修改，当另外一个事务回滚后，当前事务基于该脏数据进行修改导致数据不一致。

脏读是事务B里面修改了数据，

幻读是事务B里面新增了数据。

2. 隔离级别：锁与并发性能的权衡

为了解决以上并发事务操作存在的问题和与并发性取个折中，定义了以下四个隔离级别：

a. READ-UNCOMMITTED：读未提交
没有解决以上的任何一个问题，读写均不需要加锁，数据一致性最差，并发性能最好，存在并发操作的应用，如OLTP，基本不会使用这个隔离级别；
b. READ-COMMITTED：读提交
能够读取其他已提交事务的数据修改，不存在脏读和更新丢失问题，存在幻读和不可重复读问题。
c. REPEATABLE-READ：可重复读

解决了以上的所有问题，即不存在脏读，幻读，不可重复读和更新丢失问题，这也是MySQL的innodb存储引擎的默认隔离级别。
不可重复读的解决：读提交和可重复读的读操作都是基于MVCC机制来实现一致性无锁读取，区别在于可重复读是基于事务开始时的数据快照，整个事务期间不变，故多次读取数据一致；而读提交是基于数据的最新快照，即其他已提交事务的最新修改快照，故事务期间的两次读取可能不一样。
幻读的解决：读提交和可重复读的写操作都是基于互斥行锁实现，但是二者使用的锁的算法存在差别，读提交只锁住匹配的行，可重复读锁住匹配的行和周围的行（间隙锁的存在），即可重复读需要锁住更多的数据行，其他事务不能对这些被锁住的行进行插入、删除操作，故不会新增或减少数据行，不存在幻读发生。具体可参考：：MySQL学习（五）：Innodb存储引擎锁与MVCC机制的实现原理
REPEATABLE-READ，相对于SERIALIZABLE串行化，数据一致性方面唯一的不足是基于MVCC机制读取的数据的快照版本，故数据可能存在延迟。

d. SERIALIZABLE：串行化
解决了以上的所有问题，对读写操作均需要加锁，读操作加共享锁，写操作加互斥锁，串行化了多个事务操作，并发性能最差，数据一致性最好。