7.1  认识事务

7.1.1 概述

在事务中的操作， 要么都做修改， 要么都不做， 这就是事务的目的，也是事务模型区别与文件系统的重要特征之一。

A 原子性，

C 一致性，

I 隔离性，也可称为并发控制， 可串行化， 锁

每个读写事务的对象对其他事务的操作对象能相互分离

D 持久性

7.1.2 分类

扁平事务

带有保存点的扁平事务

链事务,  可视为保存点模式的一种变种。

嵌套事务， 是一个层次结构框架

分布式事务

7.2 事务的实现

原子性，一致性，持久性通过数据库的 redo log 和 undo Log 来完成。 redo log 称为重做日志， 用来保证事务的原子性和持久性。 undo log 用来保证事务的一致性。

redo 和 undo 不是 逆过程。redo 恢复提交事务修改的页操作， 而 undo 回滚行记录到某个特定版本。两者记录的内容不同， redo 通常是物理日志， 记录的是页的物理修改操作。 undo 是逻辑日志， 根据每行记录进行记录。

7.2.1 redo

1 基本概念

重做日志用来实现事务的持久性， 其由两部分组成： 一是内存中的重做日志缓存（redo log buffer），其是易失的； 二是日志文件（redo log file），其是持久的。

InnoDB 事务引擎，通过 Force Log at Commit 机制实现事务的持久性， 即当事务提交（commit）时， 必须先将该事务的所有日志写入到重做日志文件进行持久化， 待事务的 commit 操作完成才算完成。// 这部分写的有问题， 没分清 重做日志是只有 redo log 还是 redo log 和 undo log 两个。

redo log 基本都是顺序写的， 在数据库运行时不需要对 redo log 的文件进行读取操作， 而 undo log 是需要随机读写的。

为了确保每次日志都写入重做日志文件， 在每次将重做日志缓冲写入重做日志文件后， InnoDB 引擎都需要调用一次 fsync 操作。

由于fsync 的效率取决于磁盘的性能， 因此磁盘的性能决定了事务提交的性能， 也就是数据库的性能. // 待理解，是说数据库的性能取决于事务的性能？

参数 innodb_flush_log_at_trx_commit ，默认为 1 。 用来控制重做日志刷新到磁盘的策略。

0 表示提交时不进行写入重做日志操作，这个操作仅在 master thread 中完成， 而在 master thread 中每一秒会进行一次重做日志的 fsync 操作。//最快  

1 表示会将重做日志缓冲中的日志写入文件， 并调用一次 fsync 操作。 //最慢, 在执行 commit 时将重做日志缓冲同步到磁盘

2 表示事务提交时将重做日志写入重做日志文件， 但仅写入文件系统的缓存中， 不进行 fsync 操作。//中间 将重做日志异步写到磁盘，即写到文件系统的缓冲， 不保存执行 commit 时肯定会写入重做日志文件。

2 log block

在 InnoDB 中，重做日志都是以 512 字节进行存储的。 

日志块由三部分组成， 依次为日志块头（log block header）, 日志内容（log body）， 日志块尾（log block tailer）。

3 log group

4 重做日志格式

7.2.2 undo

1 基本概念

事务的回滚， 需要 undo

undo 是逻辑日志， 因此只是将数据库逻辑地恢复到原来的样子。 所有修改都被逻辑地取消了， 但是数据结构和页本身在回滚之后可能大不相同。因此不能将一个页回滚到事务开始的样子， 因为这样会影响其他事务正在进行的工作。

除了回滚操作， undo 的另一个作用是 mvcc ，即在 InnoDB 引擎中 MVCC 的实现是通过 undo 来完成。// 待扩充

undo log 会产生 redo log ， 也就是 undo log 的产生会伴随着 redo log 的产生， 因为undo log 也需要持久性保护。

2  undo 存储管理

show engine innodb status\G

history list length 代表了 undo log 的数量。

3 undo log 格式

undo log 分为：

insert undo log

update undo log

4 查看 undo 信息

//mysql 5.6 的 information_schema 数据库中，

//找不到表 INNODB_TRX_ROLLBACK_SEGMENT, INNODB_TRX_UNDO

7.2.3 purge

delete 和 update 操作可能并不直接删除原有的数据。

delete from t where a  = 1;

表 t 上 列 a 有聚集索引（主键）， 列 b 上有辅助索引。 对于 delete 操作， 仅是将主键列等于 1 的记录 delete flag 设置为 1， 记录并没有被删除， 即 还是存在 B+ 数中。 其次， 对辅助索引上 a 等于 1 ， b 等于 1 的记录同样没做任何处理， 针织没有产生 undo log 。 真正的删除这行记录的操作被 “延时”了， 最终在 purge 操作中完成。

purge 用来完成最终的 delete 和 update 的操作。 因为 innoDB 存储引擎支持 MVCC， 所以记录不能在事务提交时立即处理，这时其他事务可能正在引用这行， 故 innoDB 需要保存记录之前的版本。 是否可以删除通过 purge 判断。

为了节省存储空间， 一个页上允许多个事务的 undo log 存在。

全局动态参数 innodb_purge_batch_size 用来设置每次 purge 操作需要清理的 undo  page 数量， 从 1.2 版本开始，默认值为 300. 

全局动态参数 innodb_max_purge_lag 用来控制history list 的长度。默认值为 0

7.2.4 group commit

一次 fsync 可以刷新确保多个事务日志被写入文件， 事务提交时会进行两个阶段的操作：

1） 修改内存中事务对应的信息， 并且将日志写入重做日志缓冲。

2）调用 fsync 将确保日志都从重做日志缓冲写入磁盘。

步骤2）相对 1） 是一个较慢的过程， 因为要与磁盘打交道。

保证 二进制日志的写入顺序和 InnoDB 的事务提交顺序，为了备份和恢复的需要。

7.3 事务控制语句

commit 和commit work 语句基本一致， 都用来提交事务。 不同之处 commit work 用来控制事务结束后的行为是 chain 还是 release。 若果是 chain 方式， 那么事务变成了 链事务。

通过用 completion_type 来控制是否是链事务

默认为 0 ， 没有任何操作， commit 和 commit work 等价

设置为 1 ， commit work 自动开启一个链事务， 不用显示的 begin 

设置为 2 ， commit work 等同与 commit and release。 在事务提交胡会自动断开与服务器的连接

7.4 隐式提交的 SQL 语句

执行完相应语句后， 会有一个隐式的 commit 操作。此时 执行 rollback 将不可以回退

7.5 对于事务操作的统计

show global status like 'com_commit'

7.6 事务的隔离级别

READ UNCOMMITTED

READ COMMITTED 除了唯一性的约束检查及外键约束的检查需要 gap lock, InnoDB 引擎不会使用 gap lock 的锁算法。

REPEATABLE READ  使用next-key lock 锁算法， 避免幻读问题产生。

SERIALIZABLE 在此级别, InnoDB 会对每个 select 语句自动加上 lock in share mode 。 且主要用于 InnoDB 存储引擎的分布式事务。

7.7 分布式事务

7.7.1 MySql 数据库分布式事务

例子： 北京的张三转 1000 块钱到 上海的李四账户

在 PHP 中的实现：http://php.net/manual/zh/mysqlnd-ms.quickstart.xa_transactions.php

7.7.2 内部 XA 事务

另一种分布式事务：在存储引擎与插件之间，或在存储引擎与存储引擎之间。

例如：写 innodb redo 日志和 binlog 日志，要保持一致性时用到

7.8 不好的事务习惯

7.8.1 在循环中提交

7.8.2 使用自动提交

使用 start transaction, begin 来显示地开启一个事务。 在显示开启事务后， 在默认设置下（completion_type 等于 0）， mysql 会自动执行 set autocommit = 0 的命令， 并在 commit 或 rollback 结束一个事务后执行 set autocommit = 1.

7.8.3 使用自动回滚

7.9 长事务

将长事务分为若干短事务来执行。

例如：在银行系统中， 将一亿用户添加利息的操作，分为没十万个一个事务。来完成。好处是 1 不用完全回滚；2 知道进度。