事务（Transactions）
事务（Transaction） 是一种机制、一个操作序列，包含了一组数据库操作命令。
A transaction is the execution of a sequence of one or more operations (e.g., SQL queries) on a shared database to perform some higher level function. They are the basic unit of change in a DBMS. Partial transactions are not allowed (i.e. transactions must be atomic).
The Strawman System
处理事务的简单系统是使用单个工作线程（例如，一个线程）一次执行一个事务。
一次只能运行一个事务。为了执行事务，DBMS复制整个数据库文件，并将事务更改到此新文件。如果事务成功，则新文件将成为当前数据库文件。如果事务失败，DBMS将丢弃新文件，并且没有保存任何事务的更改。这种方法很慢，因为它不允许并发事务，并且需要为每个事务复制整个数据库文件。
更好的方法是允许并发执行独立事务，同时保持执行的正确性和公平性（因为所有事务都以同等优先级处理，不会因从未执行而处于饥饿状态）
但并发执行可能带来操作的任意交错，会带来以下后果:
- 暂时的不一致性：不可避免，但不是问题。
- 永久不一致：不可接受，会导致数据的正确性和完整性问题。
定义
在形式上，数据库可以表示为一组命名的数据对象（A,B,C,…）。这些对象可以是属性、元组、页面、表，甚至是数据库。我们将讨论的算法适用于任何类型的对象，但所有对象必须是同一类型。
事务是对这些对象的读写操作序列（R(A),W(B)）。
事务的边界由客户端定义。在SQL中，事务以”BEGIN“开始。事务的结果是COMMIT或者ABORT。
对于COMMIT命令，要么将事务的所有修改保存到数据库中，要么DBMS将覆盖该修改并中止。
对于ABORT命令，所有事务的更改都将被撤销，这样就好像事务从没发生过。ABORT可以是自身造成的，也可以是DBMS造成的。
ACID
- A****tomicity【原子性】：事务是一个不可分割的工作单位，事务中的操作要么都发生，要么都不发生。
- C****onsistency【一致性】：事务前后数据的完整性必须保持一致。
- I****solation【隔离性】：事务的隔离性是多个用户并发访问数据库时，数据库为每一个用户开启的事务，不能被其他事务的操作数据所干扰，多个并发事务之间要相互隔离。
- D****urability【持久性】：持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响
Atomicity
有两种方法保证原子性：
- 日志【Logging】：DBMS记录所有操作，以便可以撤消中止事务的操作。它在内存和磁盘上维护撤消记录。出于审计和效率原因，几乎所有现代系统都使用日志记录。
- 影子分页【Shadow Paging】：DBMS复制由事务修改的页面，事务对这些副本进行更改。只有当事务提交时，页面才可见。这种方法在运行时通常比基于日志的DBMS慢。但这种方法恢复起来比较简单，只需要从未提交的事务中删除所有页面。但是一般来说，更好的运行时性能优于更好的恢复性能，所以这种方法在实践中很少用。
Consistency
在高层次上，一致性意味着数据库所代表的“世界”在逻辑上是正确的。
应用程序询问有关数据的所有问题（即查询）将返回逻辑正确的结果。一致性有两个概念：
- 数据库一致性（Database Consistency）：数据库准确地表示它正在建模的真实世界实体，并遵循完整性约束。（例如，一个人的年龄不能为负值）。此外，将来的事务应该在数据库中看到过去提交的事务的影响。
- 事务一致性（Transaction Consistency）：如果数据库在事务开始之前是一致的，那么在事务开始之后也是一致的。确保事务一致性是应用程序的责任。
Isolation
DBMS提供了事务在系统中单独运行的假象。他们看不到并发事务的影响。这相当于以串行顺序（即一次一个）执行事务的系统。但为了获得更好的性能，DBMS必须在保持隔离假象的同时交错并发事务的操作。
并发控制（Concurrency Control）
并发控制协议是DBMS在运行时如何决定多个事务操作的正确交错（proper interleaving）
有两类并发控制协议：
- 悲观：DBMS假设事务将发生冲突，因此它不会让问题首先出现
- 乐观：DBMS假设事务之间的冲突很少，因此它选择在事务提交后处理冲突。
DBMS执行操作的顺序称为执行调度（execution schedule），并发控制协议的目标是生成某些串行执行等效的执行调度。
并发控制协议的目标是生成与某些串行调度等效的执行调度：
- 串行调度：不同事务之间不会交错
- 等效调度：对于任意数据库，如果执行第一个调度的效果与执行第二个调度的结果相同，则这两个调度是等效的。
- 可串行化调度：一个可串行化调度等价于任何串行调度。不同的串行调度执行后可以产生不同的结果，但都被为是“正确的”【如果一个调度是等价于一个串行调度，那么我们就说他是可串行的Serializable】
如果两个操作针对不同的事务，在同一个对象上执行，并且至少有一个操作是写操作，则会发生冲突，冲突有三种变体:
- 读-写冲突：事务在多次读取同一对象时无法获得相同的值（不可重复读取）
- 写-读冲突：在事务提交其更改前，可以看到不同事务写的效果（脏读）
- 写-写冲突：一个事务覆盖了另一个并发事务的未提交数据（丢失更新）
冲突可串行化（Conflict Serializability）
串行化有两种类型：（1）冲突和（2）视图。这两个定义都不允许将其视为可序列化的所有计划。在实践中，DBMS支持冲突序列化，因为它可以有效地实施
如果两个调度涉及相同事务的相同操作，并且每对冲突操作在两个调度中以相同的方式排序，则这两个调度是冲突等价的。如果一个调度与某个串行调度冲突等价，则该调度是冲突可串行化的。
通过交换非冲突操作直到形成串行调度，可以验证调度是否可冲突串行化。对于具有许多事务的计划，这将变得过于昂贵。验证计划的更好方法是使用依赖图dependency graph（优先图dependency graph）。
视图可串行化（View Serializability）
视图可串行化是一个较弱的可串行化概念，它允许所有冲突可串行化和“盲写”（即执行写操作而不首先读取值）的调度。因此，它允许比冲突序列化更多的调度，但很难有效实施。这是因为DBMS不知道应用程序将如何“解释”值。
Durability
提交事务的所有更改在崩溃或重新启动后都必须是持久的（即持久的）。DBMS可以使用日志记录或影子分页来确保所有更改都是持久的。