一、事务的起源

事务源于日常生活中的业务，现有这样的一个场景，A账户有11元，B账户有2元，B要向A借10元钱，此业务对应到数据库中对应两条语句，一条是将A账户的余额减10，另一条是将B账户的余额加10，但如果在刚执行完第一条语句后，服务器断电了，这该怎么办？A 的钱扣掉了，但B并没收到A转的钱。
事务可以解决上述问题，主要思想就是将上述两条语句的执行进行打包，要么这两条语句都一起执行完，要么就一条都不执行

二、事务的特性

2.1 原子性(Atomicity)

在数据库中是这样定义原子性的：要么全做，要么全部做。
现实世界中的一个不可分割的操作(例如转账)可能对应到数据库中若干条不同的操作，但在任何一个时间点数据库都可能发生错误，在MySQL中采用日志的方式保证事务的原子性

2.2 隔离性(Isolation)

在现实世界中，两次状态转换应该是互不影响的，比如A向B同时进行了两次5元转账，操作完成后A的账户金额应减少10元，B的账号金额应该增加10元，将A像B同时进行的两次操作称为T1和T2，如果T1和T2两个事务依次执行：

但在数据库中，可能是T1和T2交替执行：

如果上述操作执行完A账户金额为6，B账户金额为12，平白无故的多出10元，银行是肯定不会允许这样的事情发生的。
现实生活中的两次状态转换之间不能相互影响，这个规则就是隔离性

2.3 一致性(Consistency)

在现实世界中存在很多的约束，例如身份证号是不能重复的，性别非男即女，信号灯只有红绿黄三种颜色等，只有符合约束的数据才是有效的或说是符合一致性的。

在转账业务中的一致性要求就是：参与转化的账户的总余额不能发生改变。原子性和隔离性会对一致性产生一定的影响，如果不遵行原子性，转了一半后不转了，那这不符合一致性的要求，如果不遵行隔离性，转账完之后的总余额变多了，那么这也是不符合一致性的要求

---

一般在定义一致性需求时，只要某些数据库操作满足原子性和隔离性规则，那么这些操作执行后的结果就会满足一致性需求

2.4 持久性(Durability)

当现实世界中一次状态转换之后，这个转换的结果将会永久的保留，这个规则称为持久性，持久性对应到数据库中的就是所修改的数据都应该在磁盘中保留下来，无论以后发生什么事故，本次转换造成的结果都不应该丢失

三、事务的概念及状态

事务是一个抽象的概念，它对应着一个或多个数据库操作
事务的不同状态：

• 活动的：事务对应的数据库操作正在执行
• 部分提交的：事务中的操作都执行完成，在由于这些操作都是在内存中执行的，并没有刷新到磁盘中，此时的状态称为部分提交的
• 失败的：处于活动的或部分提交的状态时，可能遇到某些错误而无法继续执行，或人为的停止当前的事务，就说该事务处于失败状态
• 中止的：事务执行了一部分后变为失败状态，将处于失败状态的事务回滚到最初事务还有没执行时的状态，称为中止状态
• 提交的：处于部分提交状态的事务将修改过的数据都刷新到磁盘后，事务进入提交状态
  

四、支持事务的引擎

在MySQL中只有InnoDB和NDB存储引擎支持事务，MyISAM是不支持事务的