深入理解关系数据库的ACID

1.事务是构成单一逻辑工作单元的操作集合，通常由ＳＱＬ语言书写的程序执行而引发。事务是不可分割的，所以要么执行其全部内容，要么就不执行。

数据库系统维护其事务由如下性质：
－　原子性（atomicity）：事务的操作要么全部正确执行，要么全部不执行。
－　一致性（consistency）：隔离执行事务时保持数据库的一致性。
－　隔离性（isolation）：多事务并发执行时，系统保证地对于每一个事务它感觉不到系统系统中有其他事务在并发执行。
－　持久性（durability）：一个事务成功完成，它对数据库的修改必须是永久的，即使系统出现故障。
我们称这些性质为ＡＣＩＤ特性。缩写来自于４条性质的首字母。

2.我们通过一个简单的事务模型来详细描述ＡＣＩＤ特性。

read(X)：从数据库中把数据项Ｘ读出到主存缓冲区的X变量中
write(Y)：把主存缓冲区中的Y变量的值写回到数据库的数据项Y中
我们假设账户A过户５０元到B账户这样一个业务需求。我们定义这个事务为T：

T： 
      read(A);
      A:=A-50;
      write(A);
      read(B);
      B:=B+50;
      write(B);

我们逐一考虑ＡＣＩＤ特性。
－　一致性：事务的执行不改变数据库的一致性，这里就是指的事务的执行不改变A账户和B账户的和，T能保证A账户和B账户的和在T执行前后保持一致。
这种一致性主要体现在业务逻辑层面。我们要理解的重点是确保单一事务的一致性是编写该事务程序员的责任。

－　原子性：假设T执行前A账户和B账户余额分别是１０００和２０００元。我们假设故障发生在执行write(A)后，在write(B)之前。这时A账户余额是９５０，B账户余额是２０００。故障导致系统丢失了５０元。而且A和B账户的和也不再与T执行前保持一致了。这种情况我们称为不一致状态。
事实上，假设T能顺利执行完毕，在T执行过程中某一时刻也确确实实存在不一致的状态，只不过最终达到了一致的状态。
一个事务或者不开始，或者保证完成，那么不一致性状态除了在事务执行过程中体现以外，其他时刻是不可见的。这就是需要原子性的原因：事务具有原子性，某个事务的所有动作要么在数据库中全部反映出来，，要么全部不反映。

－　持久性：转账事务一旦完成，用户被告知资金转账已经发生，系统必须保证任何系统故障都不会引起数据的丢失。

－　隔离性：如果多个事务并发执行，他们的操作会以我们不希望的某种方式交叉执行，这就会导致不一致性。比如在write(A)执行完毕，write(B)还未执行时，有另外一个事务T１读取了A和B的值，它就会得到不一致的值，如果它基于这不一致的值做了后续的对A或B的更新，即使T事务和T１事务都成功执行，数据库也处于不一致状态。事务的隔离性特征能确保事务并发执行后的系统状态与这些事务以某种次序一个接一个执行后的状态是等价的。

以上就是关系数据库的ＡＣＩＤ的特性概念的详细解释。