Mysql 事务及其原理
什么是事务
什么是事务？事务是作为单个逻辑工作单元执行的一系列操作，通俗易懂的说就是一组原子性的 SQL 查询。Mysql 中事务的支持在存储引擎层，MyISAM 存储引擎不支持事务，而 InnoDB 支持，这是 Mysql 5.5.5 以后默认引擎由 MyISAM 换成 InnoDB 的最根本原因。
事务的 ACID 属性
原子性（Atomicity）：作为逻辑工作单元，一个事务里的所有操作的执行，要么全部成功，要么全部失败。
一致性（Consistency）：数据库从一个一致性状态变换到另外一个一致性状态，数据库的完整性不会受到破坏。
隔离性（Isolation）：通常来说，一个事务所做的修改在最终提交前，对其他事务是不可见的。为什么是通常来说，为了提高事务的并发引出不同的隔离级别，具体参考下一章节。
持久性（Durability）：一旦事务提交，则其所做的修改就会永久保存到数据库中，即使系统故障，修改的数据也不会丢失。
事务的隔离级别
为了尽可能的高并发，事务的隔离性被分为四个级别：读未提交、读已提交、可重复读和串行化。用户可以根据需要选择不同的级别。
未提交读（READ UNCOMMITTED）：一个事务还未提交，它的变更就能被别的事务看到。
例：事务 A 可以读到事务 B 修改的但还未提交的数据，会导致脏读（可能事务 B 在提交后失败了，事务 A 读到的数据是脏的）。
提交读（READ COMMITTED）：一个事务提交后，它的变更才能被其他事务看到。大多数据库系统的默认级别，但 Mysql 不是。
例：事务 A 只能读到事务 B 修改并提交后的数据，会导致不可重复读（事务 A 中执行两次查询，一次在事务 B 提交过程中，一次在事务 B 提交之后，会导致两次读取的结果不一致）。
可重复读（REPEATABLE READ）：未提交的事务的变更不能被其他事务看到，同时一次事务过程中多次读取同样记录的结果是一致的。 例：事务 A 在执行过程中多次获取某范围内的记录，事务 B 提交后在此范围内插入或者删除 N条记录，事务 A 执行过程中多次范围读会存在不一致，即幻读（Mysql 的默认级别，InnoDB 通过 MVVC 解决了幻读的问题）。
可串行化（SERIALIZABLE）：当两个事务间存在读写冲突时，数据库通过加锁强制事务串行执行，解决了前面所说的所有问题（脏读、不可重复读、幻读）。是最高隔离的隔离级别。
用表格可以更清晰的描述四种隔离级别的定义和可能存在的问题：
Mysql 中的事务
1、事务的自动提交
Mysql 默认采用自动提交（AUTOCOMMIT)模式，也就是说，如果不显示地开始一个事务，则每个查询都被当做一个事务执行提交操作。 可以通过以下命令查看 mysql 是否打开自动提交，
mysql> show variables like 'AUTOCOMMIT';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| autocommit | ON |
+---------------+-------+
1 row in set (0.01 sec)
--1 或者 ON 表示启用， 0 或者 OFF 表示禁用
mysql> SET AUTOCOMMIT = 0/1;
--以上命令可以打开和关闭自动提交
1、通过 set autocommit = 0 关闭当前会话的自动提交，如果需要对全局生效必须再配置文件中进行修改。
2、关闭自动提交后，用户的所有 DML 语句都会在同一个事务中，直到遇到 COMMIT 或 ROLLBACK 指令结束事务。
一张动图来说明以上两点：
当然，用户可以通过 start transaction 或者 begin 显示的开启一个事务。**显示的开启事务会自动执行 set autocommit = 0，并在 commit 或 rollback 结束一个事务后执行 set autocommit = 1。**更多事务的控制语句如下：
START TRANSACTION | BEGIN： 显式地开启一个事务；
COMMIT：也可以使用 COMMIT WORK，不过二者是等价的。COMMIT 会提交事务，并使已对数据库进行的所有修改成为永久性的；
ROLLBACK：也可以使用 ROLLBACK WORK，不过二者是等价的。回滚会结束用户的事务，并撤销正在进行的所有未提交的修改；
SAVEPOINT identifier：SAVEPOINT 允许在事务中创建一个保存点，一个事务中可以有多个 SAVEPOINT；
RELEASE SAVEPOINT identifier：删除一个事务的保存点，当没有指定的保存点时，执行该语句会抛出一个异常；
ROLLBACK TO identifier：把事务回滚到标记点；
SET TRANSACTION：用来设置事务的隔离级别。
2、事务的隔离级别
Mysql 支持事务最流行的存储引擎非 InnoDB 莫属，所以以下的 Mysql 隔离级别设置都是基于 InnoDB 的。
1、查看InnoDB存储引擎系统级的隔离级别和会话级的隔离级别，命令和结果如下：
mysql> select @@global.tx_isolation,@@tx_isolation;
+-----------------------+-----------------+
| @@global.tx_isolation | @@tx_isolation |
+-----------------------+-----------------+
| REPEATABLE-READ | REPEATABLE-READ |
+-----------------------+-----------------+
2、设置InnoDB存储引擎隔离级别：
语句：
set [ global | session ] transaction isolation level Read uncommitted | Read committed | Repeatable | Serializable;
示例：
mysql> set session transaction isolation level Serializable;
Query OK, 0 rows affected (0.01 sec)
mysql> select @@global.tx_isolation,@@tx_isolation;
+-----------------------+----------------+
| @@global.tx_isolation | @@tx_isolation |
+-----------------------+----------------+
| REPEATABLE-READ | SERIALIZABLE |
+-----------------------+----------------+
1 row in set (0.00 sec)
3、事务的 MVCC 机制
Mysql 的事务型存储引擎（InnoDB）使用 MVCC（Multi-Version Concurrency Control，多版本并发控制）代替行级锁来提高并发读写的性能。InnoDB 的 MVCC 原理比较简单，它通过在在每行记录后面保存三个隐藏列（事务 id，行的创建的版本号、行的过期版本号）来实现的，下面是 InnoDB 在 REPEATABLE READ 隔离级别下 MVCC 的简化工作原理：
INSERT: InnoDB 为新插入的每一行保存当前系统版本号作为行版本号。
UPDATE: InnoDB为插入一行新记录，保存当前系统版本号作为行版本号，同时保存当前系统版本号到原来的行作为行删除标识。
DELETE: InnoDB为删除的每一行保存当前系统版本号作为行删除标识。
SELECT: InnoDB会根据以下两个条件检查每行记录：
- InnoDB只查找版本早于当前事务版本的数据行（也就是，行的系统版本号小于或等于事务的系统版本号），这样可以确保事务读取的行，要么是在事务开始前已经存在的，要么是事务自身插入或者修改过的。
- 行的删除版本要么未定义，要么大于当前事务版本号。这可以确保事务读取到的行，在事务开始之前未被删除。
只有符合上述两个条件的记录，才能返回作为查询结果。
下面用更浅显易懂的例子说明 MVCC 下的 INSERT/DELETE/UPDATE/SELECT 操作： 假如 test 表有两个字段 name 和 age；MVCC 的三个隐藏列字段名为 transaction_id、 create_version 和 delete_version。
insert
- delete_version 未定义或者大于 select 所在事务的 delete_version 的行。
- create_version 小于或等于 select 所在事务的的 create_version。
通过这个例来看下为什么 MVCC 在 REPEATABLE READ 隔离级别下能解决幻读。假如有个事务开始于 update 之后 delete 之前，且结束于 delete 之后，如下：
start transaction; //假如事务 id = 2.5
select * from test; //执行时间在 update 之后 delete 之前
select * from test; //执行时间在 delete 之后
commit;
如果不使用 MVCC 第一条 select * from test 能读到 1 条记录，而 第二条将读取到 0 条记录，同一事务中多次 select 范围查询读取到的记录不一致即幻读。而使用 MVVC 之后，两条 select 语句读取到的记录相同。
MVCC 只在 REPEATABLE READ 和 READ COMMITTED 两个隔离级别下工作。其他两个隔离级别都和MVCC不兼容，因为 READ UNCOMMITTED 总是读取最新的数据行，而不是符合当前事务版本的数据行。而 SERIALIZABLE 则会对所有读取的行都加锁。
4、事务的实现（redo/undo log）
事务的隔离性通过锁或 MVCC 机制来实现，而原子性、持久性和一致性通过 redo/undo log 来完成。redo log 称为重做日志，用来保证事务的原子性和持久性。undo log 称为撤销日志，用来保证事务的一致性。
1、redo log
基本概念
重做日志用来实现事务的持久性，由以下两部分组成：
- 重做日志缓冲区（redo log buffer），内存中，易丢失。
- 重做日志文件（redo log file），磁盘中，持久的。
redo log file 是顺序写入的，在数据库运行时不需要进行读取，只会在数据库启动的时候读取来进行数据的恢复工作。 redo log file 是物理日志，所谓的物理日志是指日志中的内容都是直接操作物理页的命令。重做时是对某个物理页进行相应的操作。
整体流程
更新事务操作一次数据的流程图如下所示:
-
第一步：先将原始数据从磁盘中读入内存中来，修改数据的内存拷贝。
-
第二步：生成一条重做日志并写入redo log buffer，记录的是数据被修改后的值。
-
第三步：在必要的时候，采用追加写的方式将 redo log buffer 中的内容刷新到 redo log file。
-
第四步：定期将内存中修改的数据刷新到磁盘中。
以上比较重要的是第三步，其中必要的时候有以下几种情况：
- 事务提交时（最常见的情景，在 commit 之前）
- 当 log buffer 中有一半的内存空间被使用时
- log checkpoint 时
- 实例 shutdown 时
- binlog切换时
- 后台线程
写入策略
学过 linux 操作系统的都知道内存中数据写入到磁盘文件中时如果不打开 O_DIRECT 选项。数据是要先写入文件操作系统缓存区中的，然后再某个时刻 flush 到磁盘。流程如下：
事务提交时将 redo log buffer 写入 redo log file，为了保证数据一定能正确同步到磁盘（不仅仅只写到文件缓冲区中）文件中，InndoDB 默认情况下调用了 fsync 进行写操作。而 fsync 的性能比较低。当然这只是默认情况，InnoDB 也提供了参数 innodb_flush_log_at_trx_commit 来配置 redo log 刷新到磁盘的策略，有以下三个值：
- 当设置该值为 1 时，每次事务提交都要做一次 fsync，这是最安全的配置，即使宕机也不会丢失事务；
- 当设置为 2 时，则在事务提交时只做 write 操作，只保证写到系统的缓冲区，因此实例crash不会丢失事务，但宕机则可能丢失事务；
- 当设置为 0 时，事务提交不会触发 redo 写操作，而是留给后台线程每秒一次的刷盘操作，因此实例 crash 将最多丢失一秒钟内的事务。
用下图可以更直观的说明 innodb_flush_log_at_trx_commit 不同值下的不同策略。操作越接近磁盘性能越低，当然可靠性越来越高。故性能：1 < 2 < 0，可靠性：0 < 2 < 1。
恢复
InnoDB 引擎启动时不管上次数据库运行时是否正常关闭，都会尝试进行恢复操作。整个恢复操作有如下特点：
- 从 checkpoint 开始的日志部分进行恢复。
- 顺序读取及并行应用重做日志。
- 重做日志的应用具有幂等性。
- 重做日志是物理日志，恢复的速度相对较快。
2、undo log
基本概念
- undo log 用来实现事务的一致性，InndoDB 可以通过 redo log 对页进行重做操作。但是有时候事务需要进行回滚，这时就需要 undo log。
- undo log 还可可以用来协助 InnoDB 引擎实现 MVCC 机制。
- undo log 是逻辑日志，恢复时并不是对物理页直接进行恢复，而是逻辑地将数据库恢复到原来的样子。
- undo log 的产生也会伴随着 redo log 的产生。
写入时机
事务开始之前，流程如图：
在 InnoDB 中 undo log 分为 insert undo log 和 update undo log
insert undo log
insert 操作产生的日志。根据隔离性，insert 插入的记录只对本事务可见，所以事务提交后可以删除因 insert 产生的日志。
update undo log
delete 和 update 操作产生的日志。根据前面的 MVCC 机制可以知道此部分记录还有可能要被其他事务所使用，所以即使事务提交也不能删除相应的日志。在事务提交时会被保存到 undo log 链表，在 purge 线程中做最后的删除。
3、redo 与 undo log 记录过程
undo 记录更新之前的日志，为了回滚。 redo 记录更新之后的日志，为了重做。 redo log 与 undo log 产生过程的简化版本如下，可以更方便的理解 redo 与 undo 的区别。
假设有A，B两个数据，原值分别为 1, 2；现将A更新为10，B 更新为 20；undo log记录信息过程如下：
1. 事务开始
2. 记录 A = 1 到 undo log
3. 更新 A = 10
4. 记录 A = 10 到 redo log
5. 记录 B = 2 到 undo log
6. 更新 B = 20
7. 记录 B = 20 到 redo log
8. redo log 信息写入磁盘
9. 提交事务