一、事务概述
- 事务可由一条非常简单的SQL语句组成，也可以由一组复杂的SQL语句组成
- 事务是访问并更新数据库中各种数据项的一个程序执行单元
- 在事务中的操作，要么都做修改，要么都不做，这就是事务的目的，也是事务模型区别与文件系统的重要特征之一
二、事务的ACID特性
- 理论上说，事务有着极其严格的定义，它必须同时满足四个特性，通常所说的事务的ACID特性
- 值得注意的是，虽然理论上定义了严格的事务要求，但是数据库厂商出于各种目的，并没有严格去满足事务的ACID标准：
- 例如，对于 MySQL的NDB Cluster引擎来说，虽然其支持事务，但是不满足D的要求，即持久性的要求
- 对于 Oracle数据库来说，其默认的事务隔离级别为 READ COMMITTED，不满足I的要求，即隔离性的要求
- 虽然在大多数的情况下，这并不会导致严重的结果，甚至可能还会带来性能的提升，但是用户首先需要知道严谨的事务标准，并在实际的生产应用中避免可能存在的潜在问题
- 对于InnoDB存储引擎而言，其默认的事务隔离级别为READ REPEATABLE，完全遵循和满足事务的ACID特性
- 这里，具体介绍事务的ACID特性，并给出相关概念
A（Atomicity），原子性
在计算机系统中。每个人都将原子性视为理所当然。例如在C语言中调用SQRT函数，其要么返回正确的平方根值，要么返回错误的代码，而不会在不可预知的情况下改变任何的数据结构和参数。如果SQRT函数被许多个程序调用，一个程序的返回值也不会是其他程序要计算的平方根。
然而在数据的事务中实现调用操作的原子性，就不是那么理所当然了。例如一个用户在ATM机前取款，假设取款的流程为:
登录ATM机平台，验证密码。
从远程银行的数据库中，取得账户的信息
用户在ATM机上输入欲提取的金额。
从远程银行的数据库中，更新账户信息。
ATM机出款
用户取钱
整个取款的操作过程应该视为原子操作，即要么都做，要么都不做。不能用户钱未从ATM机上取得，但是银行卡上的钱已经被扣除了，相信这是任何人都不能接受的种情况。而通过事物模型，可以保证该操作的原子性。
原子性指整个数据库事务是不可分割的工作单位。只有使事务中所有的数据库操作都执行成功，才算整个事务成功。事务中任何一个SQL语句执行失败，已经执行成功的SQL语句也必须撤销，数据库状态应该退回到执行事务前的状态
如果事务中的操作都是只读的，要保持原子性是很简单的。一旦发生任何错误，要么重试，要么返回错误代码。因为只读操作不会改变系统中的任何相关部分俱是当事务中的操作需要改变系统中的状态时，例如插入记录或更新记录，那么情况可能就不像只读操作那么简单了。如果操作失败，很有可能引起状态的变化，因此必须要保护系统中并发用户访问受影响的部分数据
C（consistency），一致性
- 一致性指事务将数据库从一种状态转变为下一种一致的状态
- 在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。例如，在表中有一个字段为姓名，为唯一约束，即在表中姓名不能重复。如果一个事务对姓名字段进行了修改，但是在事务提交或事务操作发生回滚后，表中的姓名变得非唯一了，这就破坏了事务的一致性要求，即事务将数据库从一种状态变为了一种不一致的状态
- 因此，事务是一致性的单位，如果事务中某个动作失败了，系统可以自动撤销事务—返回初始化的状态
I（isolation），隔离性
- 隔离性还有其他的称呼，如并发控制、可串行化、锁等
- 事务的隔离性要求每个读写事务的对象对其他事务的操作对象能相互分离，即该事务提交前对其他事务都不可见，通常这使用锁来实现。当前数据库系统中都提供了一种粒度锁的策略，允许事务仅锁住一个实体对象的子集，以此来提高事务之间的并发度
D（durability），持久性
- 事务一旦提交，其结果就是永久性的
- 即使发生宕机等故障，数据库也能将数据恢复
- 需要注意的是：
- 只能从事务本身的角度来保证结果的永久性。例如，在事务提交后，所有的变化都是永久的。即使当数据库因为崩溃而需要恢复时，也能保证恢复后提交的数据都不会丢失
- 但若不是数据库本身发生故障，而是一些外部的原因，如RAID卡损坏、自然灾害等原因导致数据库发生问题,那么所有提交的数据可能都会丢失
- 因此持久性保证事务系统的高可靠性，而不是高可用性。对于高可用性的实现，事务本身并不能保证，需要一些系统共同配合来完成。
