扫码获取 VIP 码
添加管理员微信获取 VIP 码
在数据库管理系统中，事务是用户定义的一个数据库操作序列，这些操作要么全做要么全不做，是一个不可分割的工作单位。理解事务的ACID特性是掌握并发控制机制的必要前提。
原子性是指事务中的诸多操作要么全部成功执行要么全部不执行。如果事务在执行过程中发生故障，数据库系统必须能够将已经执行的操作全部撤销，使数据库回滚到事务开始之前的状态。原子性的实现依赖于数据库的恢复管理子系统，通常通过日志记录机制来完成。当事务开始执行时，系统会将事务的所有操作记录到日志文件中，如果事务成功提交则在日志中写入提交记录并释放资源，如果事务中途失败或被用户显式中止，系统则依据日志中的信息执行撤销操作，将数据库状态恢复到事务开始前的面貌。这种基于日志的撤销与重做机制是原子性的核心实现手段。
一致性是指事务的执行结果必须使数据库从一个一致性状态转变到另一个一致性状态，即数据库中的数据满足所有预定义的完整性约束条件。一致性是事务的根本目标，原子性、隔离性和持久性都是为一致性服务的。数据库系统可以通过约束检查、触发器等机制来保障一部分规则，但更复杂的业务逻辑一致性则需要应用程序开发者在事务代码中显式保证。例如在转账操作中，转出账户和转入账户的金额总和必须在事务执行前后保持不变。一致性实际上是数据库系统与应用程序共同承担的职责。
隔离性是指多个事务并发执行时，每个事务都感觉不到系统中其他事务的存在，就像系统在单独为它服务一样。理想情况下事务应该完全隔离互不干扰，然而完全隔离需要以牺牲系统的并发性能为代价，因此实际的数据库系统通常提供不同级别的隔离保证，让用户在一致性和性能之间做出权衡。隔离性的实现依赖于各种并发控制技术，包括锁机制、时间戳排序、多版本并发控制等，这些技术构成了后续讨论的主要内容。
持久性是指事务一旦成功提交，它对数据库所做的所有修改就永久地保存在数据库中，即使系统随后发生崩溃或故障也不会丢失。持久性的实现通常是将提交的修改数据和对应日志记录强制写入非易失性存储介质，保证系统崩溃后可通过日志重做来恢复。现代数据库广泛采用预写式日志技术，即先写日志再修改数据页，为故障恢复提供了坚实保障。
ACID四个特性中，原子性处理事务自身的执行完整性，一致性定义事务执行的目标状态，持久性解决提交结果的永久保存，而隔离性专门应对多事务并发执行时的相互干扰。隔离性的实现机制最为复杂，因为数据库系统需要在并发性能和数据正确性之间找到精妙的平衡点。
当多个事务在数据库中并发执行时，如果没有任何并发控制措施，就可能出现一系列数据不一致的异常现象。SQL标准将这些异常归纳为三大类，即脏读、不可重复读和幻读。
脏读是指一个事务读取了另一个尚未提交的事务所修改的数据。如果那个未提交的事务最终被回滚了，那么第一个事务所读取到的数据就是无效的甚至是不存在的，这种数据被称为脏数据。脏读之所以会发生，是因为在较低的隔离级别下，读取操作并不要求对数据加锁或者不要求等待其他事务释放排他锁。假设事务甲将某条记录的数值从一百修改为两百但尚未提交，此时事务乙读取了这条记录并得到数值两百，如果事务甲随后因为某种原因回滚数值恢复为一百，那么事务乙读到的两百就是一个从未真正存在过的值。脏读的危害在于它违反了隔离性原则，使得一个事务的执行结果受到另一个未完成事务的影响，在实际应用中可能导致基于错误数据做出关键业务决策。
不可重复读是指在一个事务内部，对同一条数据记录进行两次读取，两次读取之间另一个事务对该记录进行了修改并提交，导致两次读取的结果不一致。这种异常之所以被称为不可重复读，是因为在同一个事务中重复读取同一条数据却得到了不同的结果。不可重复读与脏读的区别在于，脏读读到的是未提交的数据，而不可重复读读到的是另一个事务已经提交的更新。从严格意义上讲不可重复读并不完全违反数据的正确性，因为它读取的始终是已经提交的有效数据。然而当事务需要基于第一次读取的结果做出判断和决策时，第二次读取结果的变化可能导致整个逻辑走向错误的方向。例如一个事务先查询某个账户的余额为一千元，然后根据这个余额进行一系列计算，在计算过程中另一个事务修改了余额并提交，当事务再次查询余额时发现数值变为八百元，那么之前基于一千元所做的所有计算都将失去意义。
幻读是指在一个事务内部按照相同的查询条件进行两次查询，第二次查询的结果集中出现了第一次查询时不存在的新增数据行，或者缺少了第一次查询时存在的某些数据行。这些多出来或者消失不见的行被称为幻影行，幻读因此得名。幻读与不可重复读虽然都属于重复读取不一致的问题，但它们涉及的层面不同。不可重复读针对的是同一条记录的内容发生了变化，而幻读则针对的是一个查询条件所覆盖的数据集合的成员发生了变化。造成幻读的根本原因在于另一个事务插入或删除了符合查询条件的记录并提交。幻读在实际应用中的影响往往比不可重复读更加隐蔽和深远。如果事务对查询结果集进行了聚合计算，例如统计总数或求取平均值，那么幻读导致的集合变化会使聚合结果失真。如果事务试图对整个查询结果集执行批量更新操作，幻读可能导致某些本该被更新的记录被遗漏，从而破坏数据一致性。
为了在并发性能和数据一致性之间提供灵活的权衡空间，SQL标准明确了四个渐次增强的事务隔离级别，分别是读未提交、读已提交、可重复读和可串行化。每个级别通过禁止特定种类的并发异常来定义自身的一致性保证强度，级别越高所能防范的异常种类越多，但并发性能往往越低。
读未提交是最低的隔离级别。在这个级别下一个事务可以读取到其他事务尚未提交的修改，也就是说读未提交不禁止脏读，同时它也无法防止不可重复读和幻读。读未提交通常只在一些对数据精确性要求极低但对性能要求极高的场景下使用，例如某些实时统计报表系统允许统计结果存在一定程度的误差。在实际的企业级应用中读未提交极少被用作默认隔离级别。
读已提交是大多数数据库系统的默认隔离级别。在这个级别下事务只能读取到其他事务已经提交的数据，因此脏读被禁止，但并不能防止不可重复读和幻读。读已提交的实现方式通常是让读取操作在读取完成后立即释放共享锁，这使得其他事务可以在两次读取之间修改数据并提交。读已提交提供了一种基本的数据一致性保障，能够防止读取到未确认的中间状态数据，对于大多数普通的在线事务处理场景而言已经足够。
可重复读是一个更高级别的隔离保障。在这个级别下不仅脏读被禁止，不可重复读也被禁止。也就是说一个事务在执行期间即使其他事务修改了同一条记录并提交，该事务重复读取同一条数据时看到的始终是事务开始时的一致快照。可重复读的实现需要数据库系统在事务持续期间保持读取锁，或者采用多版本并发控制机制为事务提供一致的数据快照。需要留意的是SQL标准中定义的可重复读级别并不能防止幻读，但在具体的数据库实现中不同产品对可重复读的处理方式有所不同。
可串行化是最高的事务隔离级别，所有三种并发异常都被禁止，事务并发执行的结果必须与这些事务按照某种串行顺序逐个执行的结果完全相同。可串行化强制要求事务之间的执行效果看起来就像是按照某个全局的线性顺序依次执行的，从根本上消除了并发执行可能带来的所有数据不一致问题。然而实现可串行化通常需要大量使用锁机制或者采用激进的冲突检测策略，这会导致系统并发吞吐量大幅下降。因此可串行化一般只在对数据一致性要求极为严格的场景下使用，例如金融系统中的资金清算和证券交易中的订单匹配等核心环节。
不同数据库对四个隔离级别的实现各有特色。Oracle默认采用读已提交并额外提供只读事务和可串行化两种选项。MySQL的InnoD
本篇完！