事务（Transaction）是数据库区别于文件系统的重要特性之一。
数据库引入事务的主要目的：事务会把数据库从一种抑制状态转换为另一种一致状态。在数据库提交工作时，要么所有修改都已经保存了，要么所有修改都不保存。
InnoDB中的事务完全符合ACID的特性

• 原子性（atomicity）
• 一致性（consistency）
• 隔离性（isolation）
• 持久性（durability）

7.1 事务概述

事务用来保证数据库的完整性
原子性：事务中所有操作要么全部成功，要么全部失败
一致性：从一种状态转变为下一种一致状态。事务开始前和结束后，数据库的完整性约束没有被破坏。
隔离性：一个事务的影响在提交前对其他事务都不可见
持久性：一旦提交，结果就是永久性的。

7.2 事物的实现

隔离性由锁实现
原子性，一致性，持久性通过数据库的Redo Undo实现

7.2.1 redo

• 事务日志由重做日志（redo）文件和InnoDB日志缓冲（InnoDB Log Buffer）实现。
• 当开始一个事务时，会记录该事务的
  LSN，日志序列号。
• 事务执行时，会往InnoDB日志缓冲里插入事务日志。
• 事务提交时，必须将InnoDB日志缓冲写入磁盘，再写数据，即预写日志方式。从而保证数据完整性

7.2.2 undo

undo存放在数据库内部的一个特殊段中，成为undo段，undo段位于共享表空间内。
undo只能逻辑上还原，并不能物理上还原

7.3 事务控制语句

• START TRANSACTION | BEGIN ： 显示的开启一个事务，存储过程中只能使用START TRANSACTION。
• COMMIT ：提交事务，并使得一堆数据库做的所有修改成为永久性的。commit work在completion_type不同时会执行不同的操作。
• ROLLBACK ：结束事务并撤销正在进行的所有未提交的修改。
• SAVEPOINT identifier：SAVEPOINT允许你在事务中创建一个保存点，一个事务中可以有多个SAVEPOINT。
• RELEASE SAVEPOINT identifier：删除一个保存点，当没有保存点时会报错，此条回滚并不会像ROLLBACK一样结束事务。
• ROLLBACK TO [SAVEPOINT] identifier：这个语句与SAVEPOINT命令一起使用。回滚到保存点位置
• SET TRANSACTION：这个语句用来设置事务的隔离级别。

7.4 隐式提交的SQL语句

以下语句会隐式提交事务

隐式提交

Microsoft SQL Server 中DDL不会隐式提交，这一点与InnoDB和Oracle不同

7.5 对于事务操作的统计

TPS计算：

(com_committed + com_rollback) / time
但是这种方法的前提是所有的事务都必须是显示提交的。如果存在饮食的提交和回滚（默认autocommit=1），不会计算到com_commit和com_rollback中

7.6 事务的隔离级别

隔离级别有四个

• READ UNCOMMITTED
• READ COMMITTED
• REPEATABLE READ
• SERIALIZABLE
  InnoDB默认为REPEATABLE READ ，通过Next-Key Lock锁的算法，避免了幻读，已经能完全保证事务的隔离性要求。

7.7 分布式事务

• InnoDB支持XA事务，通过XA事务可以支持分布式事务的实现。
• 分布式事务指允许多个独立的事务资源参与一个全局的事务中。全局事务要求参与的事务要么都提交，要么都回滚，所以对于事务原有的ACID有了更高的要求。另外，使用分布式事务时，InnoDB事务隔离级别必须是SERIALIABLE。

• XA事务允许不同数据库之间的分布式事务。

  
  分布式事务模型

分布式事务使用两段式提交（two-phase commit）的方式。

• 在第一个阶段，所有参与的节点都开始准备（PREPARE），告诉事务管理器他们准备好提交了。
• 第二个阶段，事务管理器告诉资源管理器执行ROLLBACK还是COMMIT。如果任何一个节点显示不能提交，则所有节点都被告知需要回滚。

7.8 不好的事务习惯

7.8.1 在循环中提交

循环中重复提交，或者隐式提交，都会重复写入重做日志，造成资源浪费。

7.8.2 使用自动提交

7.8.3 使用自动回滚

无法获取返回值和报错信息，所以事务的控制应该交给程序端。