事务
事务(transaction)是数据库系统区别于文件系统的重要特性之一。在文件系统中，如果用户正在写文件，但是操作系统突然崩溃了，这个文件可能就会被破坏。当然，有一些机制可以把文件恢复到某个时间点。不过，如果需要保证多个文件同步，这些文件系统可能就显得无能为力了。例如:当更新两个文件时，更新完一个文件后，在更新完第二个文件之前系统重启了，你就会得到两个不同步的文件。在SQL编程中，事务编程保证数据库从一种状态转换为另一种一致状态。在数据库提交工作时，可以确保其要么对所有修改都已经保存，要么对所有修改操作都不保存。
事务其实就是一组DML(insert,delete, update)语句的集合。MySQL数据库InnoDB存储引擎支持事务，MyISAM不支持。而且MySQL的事务默认是自动提交模式，如果想要开启事务，必须以begin命令开始，以 commit或者rollback命令结束。
1.1事务概述
事务可以由一条非常简单的SQL语句组成，也可以由一组复杂的SQL语句组成。事务是访问并更新数据库中各种数据项的一个程序执行单元。在事务中的操作，要么都执行修改，要么都不执行，这就是事务的目的，也是事务模型区别于文件系统的重要特征之一。
从理论上说，事务有着及其严格的定义，它必须同时满足4个特性，即通常所说的事务的ACID特性。
1. A(atomicity)，原子性。原子性指的是整个数据库事务是不可分割的工作单位。只有使得事务中所有的数据库操作都执行成功，整个事务的执行才算成功。事务中的任何一个SQL语句执行失败，那么已经执行成功的SQL语句也必须撤销，数据库状态应该退回到执行事务前的状态。
例如一个用户在ATM机前取款，其取款的流程为:
1)登录ATM机平台，验证密码。
2)从远程银行的数据库中取得账户的信息。
3)用户在ATM机上输入欲提取的金额。
4)从远程银行的数据库更新账户的信息。
5)ATM机出款。
6)用户取钱。
整个取款的操作应该视为原子操作。要么都做，要么都不做。不能出现用户钱未从ATM机上取得而银行卡上的钱已经被扣除的情况。通过事务模型，可以保证该操作的原子性。
2. C(consistency), 一致性。一致性值的是事务将数据库从一种状态变为另一种一致的状态。在事务开始之前和事务结束之后，数据库的完整性约束没有被破坏。例如在表中有个字段为姓名，它是一个唯一约束，即在表中姓名不能重复。如果一个事务对表进行了修改，但是在事务提交或当前事务操作发生回滚后，表中的数据姓名变得非唯一了，那么就破坏了事务的一致性要求，即事务将数据库从一种状态变为了一种不一致的状态。事务是一致性的单位，如果事务中某个动作失败了，系统可以自动的撤销事务使其返回初始化的状态。
3. I(isolation)，隔离性。事务的隔离性要求每个读写事务的对象与其他事物的操作对象能相互分离，即该事务提交前对其他事物都不可见，这通常使用锁来实现。允许多个并发事务同时对数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。比如，在甲乙之间转账时，丙同时向甲转账，若同时进行，则甲乙之间的一致性不能得到满足。所以在甲乙事务执行过程中，其他事务不能访问(修改)当前相关的数值。
4. D(durability)，持久性。事务一旦提交，其结果就是永久性的，即是发生宕机等故障，数据库也能将数据恢复。
1.2 事务的分类
从事务理论的角度来看，可以把事务分为以下几种类型
扁平事务(Flat Transactions)
带有保存点的扁平事务(Flat Transactions with Savepoints)
链事务(Chained Transactions)
嵌套事务(Nested Transactions)
分布式事务(Distributed Transactions)
扁平事务 是事务类型中最简单的一种，但是在实际生产环境中，这可能是使用最频繁的事务，在扁平事务中，所有操作都处于同一层次，其由BEGIN WORK开始，由COMMIT WORK或ROLLBACK WORK结束，其间的操作是源自的，要么都执行，要么都回滚，因此扁平事务是应用程序称为原子操作的的基本组成模块
下面显示了扁平事务的三种不同结果
给出的扁平事务的三种情况，同时也给出了一个典型的事务处理应用中，每个结果大概占用的百分比。再次提醒，扁平事务虽然简单，但是在实际环境中使用最为频繁，也正因为其简单，使用频繁，故每个数据库系统都实现了对扁平事务的支持
扁平事务的主要限制是不能提交或者回滚事务的某一部分，或分几个步骤提交。下面给出一个扁平事务不足以支持的例子。例如用户在旅行网站上进行自己的旅行度假计划，用户设想从杭州到意大利的佛罗伦萨，这两个城市没有直达的班机，需要用户预订并转呈航班，需要或者搭火车等待。用户预订旅行度假的事务为
BEGIN WORK：
S1：预订杭州到上海的高铁
S2：上海浦东国际机场坐飞机，预订到米兰的航班
S3：在米兰转火车前往佛罗伦萨，预订去佛罗伦萨的火车
但是当用户执行到S3时，发现由于飞机到达米兰的时间太晚，已经没有当天的火车，这时用户希望在米兰当地住一晚，第二天出发去佛罗伦萨。这时如果事务为扁平事务，需要回滚之前S1 S2 S3的三个操作，这个代价明显很大，因为当再次进行该事务是，S1 S2的执行计划是不变的，也就是说，如果支持有计划的回滚操作，那么不需要终止整个事务，因此就出现了带有保存点的扁平事务
带有保存点的扁平事务 除了支持扁平事务支持的操作外，允许在事务执行过程中回滚同一事务中较早的一个状态。这是因为某些事务可能在执行过程中出现的错误并不会导致所有的操作都无效，放弃整个事务不合乎要求，开销太大，保存点用来通知事务系统应该记住事务当前的状态，以便当之后发生错误时，事务能回到保存点当时的状态
对于扁平的事务来说，隐式的设置了一个保存点。然而整个事务中，只有这一个保存点，因此，回滚只能会滚到事务开始时的状态，保存点用SAVE WORK函数来建立，通知系统记录当前的处理状态。当出现问题时，保存点能用作内部的重启动点，根据应用逻辑，决定是回到最近一个保存点还是其他更早的保存点。图显示了事务中使用的保存点
显示了如何在事务中使用保存点，灰色背景部分表示由ROLLBACK WORK而导致部分回滚，实际并没有执行操作，当用BEGIN WORK开启一个事务时，隐式地包含了一个保存点，当事务通过ROLLBACK WORK：2发出部分回滚命令时，事务会滚到保存点2，接着依次执行，并再次执行到ROLLBACK WORK：7，知道最后COMMIT WORK操作，表示事务结束，除灰色阴影部分的操作外，其余操作都已经执行，并且提交
另一个需要注意的是，保存点在事务内部是递增的，从图中可以看出，有人可能会想，返回保存点2以后，下一个保存点可以为3，因为之前的工作已经终止，然而新的保存点编号为5，这意味着ROLLBACKU 不影响保存点的计数，并且单调递增编号能保持事务执行的整个历史过程，包括在执行过程中想法的改变
此外，当事务通过ROLLBACK WORK：2命令发出部分回滚命令时，要记住事务并没有完全被回滚，只是回滚到保存点2而已，这代表当前事务是活跃的，如果想要回滚事务，还需要执行ROLLBACKUP WORK
链事务 可视为保存点模式的一种变种，带有保存点的扁平事务，当发生系统崩溃是，所有的的保存点都将消失，因为其保存点是易失的，这意味着当进行恢复时，事务需要从开始处重新执行，而不能从最近的一个保存点继续执行
链事务的思想是：在提交一个事务时，释放不需要的数据对象，将必要的处理上下文隐式地传给下一个要开始的事务，提交事务操作和开始下一个事务操作 将合并为一个原子操作，这意味着下一个事务将看到上一个事务的结果，就好像一个事务中进行的一样，如图显示了链事务的工作方式
链事务与带有保存点的扁平事务不同的是，带有保存点的扁平事务能回滚到任意正确的保存点，而链事务中的回滚仅限当前事务，即只能恢复到最近的一个保存点，对于锁的处理，两者也不相同，锁事务在执行COMMIT后即释放了当前所持有的锁，而带有保存点的扁平事务不影响迄今为止所持有的锁
嵌套事务 是一个层次结构框架，由一个顶层事务(top-level transaction)控制着各个层次的事务，顶层事务之下嵌套的事务被称为子事务，其控制每一个局部的变换，结构如下
下面给出MOSS对嵌套事务的定义
1 嵌套事务是由若干事务组成的一棵树，子树既可以是嵌套事务也可以是扁平事务
2 处在叶节点的事务是扁平事务，但是每个事务从根到叶节点的距离可以说是不同的
3 位于根节点的事务称为顶层事务，其他称为自事务。事务的前驱称(predecessor)为父事务(parent)，事务的下一层称为儿子事务(child)
4 子事务既可以提交也可以回滚。但是它的提交操作并不马上生效。除非其父事务已经提交。因此可以推论出，任何子事务都在顶层事务提交后才真正的提交
5 树中的任意事务回滚会引起它的所有子事务一同回滚，故子事务仅保留ACI特性而不具有D特性
在Moss的理论中，实际的工作是交由叶子节点完成，即只有叶子节点的事务才能才能访问数据库、发送信息、获取其他类型的资源。而高层的事务仅负责逻辑控制。决定合适调用相关的子事务。即使一个系统不支持嵌套事务，用户也可以通过保存点技术来模拟嵌套事务，如图
如图可以发现，在恢复时采用保存点技术比嵌套查询有更大的灵活性。例如在完成Tk3这事务时，可以会滚到保存点S2的状态。而在嵌套查询的层次结构中，这是不被允许的
但是用保存点技术来模拟嵌套事务在锁的持有方面还是与嵌套查询有些区别。当通过保存点技术来模拟嵌套事务时，用户无法选择哪些锁需要被子事务集成，哪些需要被父事务保留，这就是说，无论有多少个保存点，所有被锁住的队形都可以被得到和访问。而在嵌套查询中，不同的子事务在数据库对象上持有的锁是不同观点。例如一个父事务P1 其持有对象X和Y的排他锁，现在要开始调用子事务P11 ,那么父事务P1 可以不传递锁，也可以传递所有的锁，也可以只传递一个排他锁，如果子事务P11 中还持有对象Z的排他锁，那么通过反向继承(counter-inherited)父事务P1 将持有3个对象X Y Z的排他锁。如果这时再次调用一个子事务P12 ，那么它可以传递哪里已经持有的锁
然而，如果系统支持嵌套事务中并行地执行的各个子事务，在这种情况下，采用保存点的扁平事务来模拟嵌套事务就不切实际了。这从另一个方面反映出，想要实现事务间的并行性，需要真正支持的嵌套事务
分布式事务 通常是一个分布式环境下运行的扁平事务，因此需要根据数据所在位置访问网络中的不同节点
假如一个用户在ATM机上进行银行的转账操作，例如持卡人从招商银行存储卡转账10 000 元到工商银行的存储卡。这种情况下，可以将ATM机视为节点A，招商银行的后台数据库视为节点B，工商银行的后台数据库视为C，这个转账的操作可分解为以下的步骤
节点A发出转账命令
节点B执行存储卡中的余额减去10 000
节点C执行存储卡终端的余额增加10 000
节点A通知用户操作完成或者节点A通知用户操作失败
这里需要使用到分布式事务，因为节点A不能通过一台数据库就完成任务，其需要访问网络中两个节点的数据库，而在每个节点的数据库执行的实务操作有都是扁平的，对于分布式事务，其同样需要满足ACID特性，要么都发生，要么都失败。对于上述例子，如果2 3 步中任何一个操作失败，都会导致整个分布式事务回滚，若非这样，结果非常可怕
对于InnoDB存储引擎来说，其支持扁平事务，带保存点的事务，链事务，分布式事务。对于嵌套事务，其原生不支持。因此对有并发事务需求的用户来说,MySQL数据库或InnoDB存储引擎就显得无能为力，然而用户仍可以通过带保存点的事务来模拟串行的嵌套事务
1.3 事务控制语句
还没想好咋整理，放个坑在这里。
1.4 事务的隔离级别
MySQL InnoDB存储引擎SQL标准的4种隔离级别，用来限定事务内外的哪些改变是可见的，哪些是不可见的。低级别的隔离级一般支持更高的并发处理，并且拥有更低的系统开销。
MySQL数据库通过下面命令来查看当前数据库的隔离级别。
4种隔离级别如下：
- 读未提交(read uncommitted)，简称RU---------在其中一个事务中，可以读取到其他事务未提交的数据变化。这种读取其他会话还没提交的事务，叫作脏读现象。在生产环境中不建议使用。
- 读已提交(read committed),简称RC-----------在其中一个事务中，可以读取到其他事务已经提交的数据变化。这种读取也可以叫做不可重复读，允许幻读现象发生，是Oracle数据库默认的事务隔离级别。
- 可重复读(repetable read),简称RR-----------,它是MySQL默认的事务隔离级别，在其中一个事务中，直到事务结束前，都可以反复读取事务刚开始时看到的数据，并一直不会发生变化，避免了脏读，不可重复读和幻读现象的发生。
- 串行(serializable)-------------在每个读的数据行上都需要加表级共享锁，在每次写数据时都要加表级排他锁。这就会造成InnoDB的并发能立下降，下量的超时和锁竞争就会发生。不建议使用到生产环境中。
1.5 细说脏读，不可重复读，幻读，可重复读现象
1.5.1 脏读
脏读是在事务隔离级别读未提交(RU)中出现的现象。一个事务读取到了其他事务还没有提交的数据。事务隔离级别的名称是读未提交(RU)。
A事务执行过程中，B事务读取了A事务的修改。但是由于某些原因，A事务可能没有完成提交，发生RollBack了操作，则B事务所读取的数据就会是不正确的。这个未提交数据就是脏读（Dirty Read）。脏读产生的流程如下：
1.5.2 不可重复读与幻读
不可重复读是指在其中一个事务中，读取到了其他事务针对旧数据的修改记录。(常见的操作是update或者delete语句)
B事务读取了两次数据，在这两次的读取过程中A事务修改了数据，B事务的这两次读取出来的数据不一样。B事务这种读取的结果，即为不可重复读（Nonrepeatable Read）。不可重复读的产生的流程如下：
幻读:幻读是指在其中的一个事务中，读取到了其他事务新增的数据，仿佛出现了幻影现象。(常见的操作就是insert语句)。这种读的现象允许出现在读已提交的事务隔离级别中。
B事务读取了两次数据，在这两次的读取过程中A事务添加了数据，B事务的这两次读取出来的集合不一样。幻读产生的流程如下：
这个流程看起来和不可重复读差不多，但幻读强调的集合的增减，而不是单独一条数据的修改。