SQL数据库中事务的ACID特性

发布时间：2010-09-08 15:55 来源：未知

作为SQL数据库的使用者，事务是必须要掌握的，接下来的SQL server内容就将为您介绍SQL数据库中事务的ACID特性，供您参考，希望对您有所帮助。

当事务处理系统创建事务时，将确保事务有某些特性。组件的开发者们假设事务的特性应该是一些不需要他们亲自管理的特性。这些特性称为ACID特性。

ACID就是：原子性(Atomicity )、一致性( Consistency )、隔离性( Isolation)和持久性(Durabilily)。

1. 原子性

原子性属性用于标识事务是否完全地完成，一个事务的任何更新要在系统上完全完成，假如由于某种原因出错，事务不能完成它的全部任务，系统将返回到事务开始前的状态。

让我们再看一下银行转帐的例子。假如在转帐的过程中出现错误，整个事务将会回滚。只有当事务中的所有部分都成功执行了，才将事务写入磁盘并使变化永久化。

为了提供回滚或者撤消未提交的变化的能力，许多数据源采用日志机制。例如，SQL Server使用一个预写事务日志，在将数据应用于(或提交到)实际数据页面前，先写在事务日志上。但是，其他一些数据源不是关系型数据库管理系统(RDBMS)，它们管理未提交事务的方式完全不同。只要事务回滚时，数据源可以撤消所有未提交的改变，那么这种技术应该可用于管理事务。

2. 一致性

事务在系统完整性中实施一致性，这通过保证系统的任何事务最后都处于有效状态来实现。假如事务成功地完成，那么系统中所有变化将正确地应用，系统处于有效状态。假如在事务中出现错误，那么系统中的所有变化将自动地回滚，系统返回到原始状态。因为事务开

始时系统处于一致状态，所以现在系统仍然处于一致状态。

再让我们回头看一下银行转帐的例子，在帐户转换和资金转移前，帐户处于有效状态。假如事务成功地完成，并且提交事务，则帐户处于新的有效的状态。假如事务出错，终止后，帐户返回到原先的有效状态。

记住，事务不负责实施数据完整性，而仅仅负责在事务提交或终止以后确保数据返回到一致状态。理解数据完整性规则并写代码实现完整性的重任通常落在开发者肩上，他们根据业务要求进行设计。

当许多用户同时使用和修改同样的数据时，事务必须保持其数据的完整性和一致性。因此我们进一步研究A C I D特性中的下一个特性：隔离性。

3. 隔离性

在隔离状态执行事务，使它们好像是系统在给定时间内执行的唯一操作。假如有两个事务，运行在相同的时间内，执行相同的功能，事务的隔离性将确保每一事务在系统中认为只有该事务在使用系统。

这种属性有时称为串行化，为了防止事务操作间的混淆，必须串行化或序列化请求，使得在同一时间仅有一个请求用于同一数据。

重要的是，在隔离状态执行事务，系统的状态有可能是不一致的，在结束事务前，应确保系统处于一致状态。但是在每个单独的事务中，系统的状态可能会发生变化。假如事务不是在隔离状态运行，它就可能从系统中访问数据，而系统可能处于不一致状态。通过提供事

务隔离，可以阻止这类事件的发生。

在银行的示例中，这意味着在这个系统内，其他过程和事务在我们的事务完成前看不到我们的事务引起的任何变化，这对于终止的情况非常重要。假如有另一个过程根据帐户余额进行相应处理，而它在我们的事务完成前就能看到它造成的变化，那么这个过程的决策可能

建立在错误的数据之上，因为我们的事务可能终止。这就是说明了为什么事务产生的变化，直到事务完成，才对系统的其他部分可见。

隔离性不仅仅保证多个事务不能同时修改相同数据，而且能够保证事务操作产生的变化直到变化被提交或终止时才能对另一个事务可见，并发的事务彼此之间毫无影响。这就意味着所有要求修改或读取的数据已经被锁定在事务中，直到事务完成才能释放。大多数数据库，例如SQL Server以及其他的RDBMS，通过使用锁定来实现隔离，事务中涉及的各个数据项或数据集使用锁定来防止并发访问。

4. 持久性

持久性意味着一旦事务执行成功，在系统中产生的所有变化将是永久的。应该存在一些检查点防止在系统失败时丢失信息。甚至硬件本身失败，系统的状态仍能通过在日志中记录事务完成的任务进行重建。持久性的概念允许开发者认为不管系统以后发生了什么变化，完

成的事务是系统永久的部分。