1 基本概念
1.1 事务的定义
事务是数据库系统中的一个逻辑工作单元，由若干个操作组成，这些操作在逻辑上应被视为一个整体。它通常遵循“全部成功或全部失败”的处理原则：一旦事务中的任一环节出现异常，系统便会撤销已执行的部分，以避免数据处于中间状态。事务不仅用于数据库读写，也常见于需要统一提交结果的业务处理过程。
1.2 事务的核心特征
事务之所以被广泛采用，关键在于它具备一组用于保证可靠性的基本属性，通常概括为原子性、一致性、隔离性和持久性。这些特征共同构成了事务处理的理论基础，也是数据库管理系统设计的重要目标。
1.2.1 原子性
原子性指事务中的多个操作不可被拆分为独立生效的部分。事务执行时，系统要么完成全部步骤，要么在失败时撤销已执行内容，使数据恢复到事务开始前的状态。该特性使事务具备“整体动作”的意义。
1.2.2 一致性
一致性要求事务执行前后，数据必须满足既定规则与约束，例如主键唯一、外键有效、余额不为负等。事务本身不直接定义业务规则，但它通过成功提交或完整回滚，帮助系统维持数据的逻辑正确性。
1.2.3 隔离性
隔离性表示多个事务并发执行时，一个事务的中间结果不应被其他事务随意读取或干扰。不同数据库会通过锁、版本控制或其他并发控制技术实现不同程度的隔离，以减少脏读、不可重复读和幻读等现象。
1.2.4 持久性
持久性是指事务一旦提交，其结果应被永久保存，即使随后发生系统故障，已提交的数据也不应丢失。为实现这一点，数据库通常依赖日志、刷盘和恢复机制来保证提交结果可追溯、可重建。
1.3 事务的作用
事务不仅是数据库内部的执行单位，也是一种控制数据变化过程的机制。它将复杂操作封装为可控的整体，便于系统在并发、故障和恢复场景下维持稳定运行。
1.3.1 数据完整性保障
事务能够将一组相关变更绑定在一起，防止只完成其中一部分而造成逻辑错误。例如，在同时更新账户余额与流水记录时，事务可确保两者同步成功，避免数据出现不一致状态。
1.3.2 并发执行协调
在多用户或多线程环境下，事务可协调不同操作对共享数据的访问次序，降低冲突风险。通过合理的并发控制，系统既能提高吞吐量，又能尽量保持结果正确。
1.3.3 错误恢复支持
当执行过程中出现断电、程序崩溃或约束违反等问题时，事务机制可以借助回滚和日志恢复，把数据库修复到可用状态。这使系统具有较强的容错能力。
2 事务的执行过程
2.1 事务开始
事务通常从显式或隐式的开始指令进入活动状态。此时系统会为事务分配标识，并准备相应的上下文信息，如锁状态、日志记录位置和版本信息。开始阶段标志着事务生命周期正式启动。
2.2 事务执行
事务进入执行阶段后，会依次进行读写操作，并根据需要申请资源。不同数据库在实现上可能略有差异，但基本逻辑都是围绕数据访问、冲突检测和状态维护展开。
2.2.1 读操作
读操作用于从数据库中获取数据。事务在读取时，可能会根据隔离级别看到其他事务已提交的结果，也可能只看到自身可见的版本。读操作的表现直接影响并发行为和结果一致性。
2.2.2 写操作
写操作是对数据进行修改、插入或删除的过程。写入通常不会立刻对外永久生效，而是先保存在事务上下文中，等待提交时统一落地。这样可以为回滚留下空间。
2.2.3 锁与资源申请
在执行过程中，事务常需申请锁或其他资源，以保证访问冲突得到控制。不同类型的锁对应不同的保护范围，例如共享锁用于读取，排他锁用于修改。资源申请顺序若处理不当，也可能引发等待或死锁。
2.3 事务提交
提交是事务生命周期中最关键的步骤之一。系统在确认所有操作成功、约束检查通过后，会将事务结果正式写入数据库，并释放相关资源。提交一旦完成，事务的修改通常被视为不可逆的正式结果。
2.4 事务回滚
回滚用于撤销尚未提交的事务所产生的变更。它可以由错误触发，也可以由用户主动发起。回滚过程会把数据恢复到事务开始前的状态，从而避免异常操作污染正式数据。
3 事务控制机制
3.1 并发控制
并发控制是事务系统的重要组成部分，目标是在多个事务同时运行时保持正确性。它通过规则、协议和调度策略协调访问顺序，尽量减少相互干扰。
3.1.1 锁机制
锁机制是最常见的并发控制手段之一。系统在事务访问数据前先加锁，从而限制其他事务对同一资源的操作。锁可以按粒度分为表锁、行锁等，也可以按用途分为读锁、写锁等。
3.1.2 时间戳排序
时间戳排序通过为事务分配时间标记，按照时间先后决定操作能否执行。其核心思想是用全局顺序减少冲突，使并发事务在逻辑上符合某种既定排列。
3.1.3 多版本并发控制
多版本并发控制允许系统同时保存同一数据的多个版本。读操作可访问某一稳定版本，而写操作则生成新版本。该方法常用于提升读多写少场景下的并发性能，并减少读写互锁。
3.2 隔离级别
隔离级别定义了事务之间相互可见的程度。不同级别在一致性与性能之间作出不同取舍，应用系统通常会根据业务需求选择合适方案。
3.2.1 读未提交
读未提交允许一个事务读取另一个事务尚未提交的数据。该级别并发效率较高，但容易出现脏读，因此通常只在对准确性要求不高的场景中使用。
3.2.2 读已提交
读已提交要求事务只能看到其他事务已提交的数据。它能避免脏读，但在多次读取同一记录时，仍可能因为其他事务提交而看到不同结果。
3.2.3 可重复读
可重复读保证在同一事务内，对同一数据的多次读取结果保持一致。该级别可减少数据在事务期间发生变化带来的干扰，但在某些实现中仍可能出现范围查询相关的问题。
3.2.4 可串行化
可串行化是最高级别的隔离要求，表示并发执行的事务效果应等价于某种串行顺序。它提供最强的一致性保障，但通常伴随更高的资源消耗和更低的并发度。
3.3 死锁处理
当多个事务相互等待对方持有的资源时，就可能形成死锁。死锁处理机制用于发现、预防和解除这类循环等待现象。
3.3.1 死锁检测
死锁检测通过观察等待图或相关状态信息，判断系统中是否存在相互依赖的环路。一旦确认死锁，系统便可定位涉及的事务并采取后续措施。
3.3.2 死锁预防
死锁预防通过约束资源申请方式，尽量避免形成环路。例如，统一加锁顺序、限制等待条件或在冲突时直接终止部分事务，都是常见做法。
3.3.3 死锁恢复
死锁恢复是在死锁发生后，通过回滚某些事务来打破等待循环。恢复策略通常会考虑事务代价、执行进度和影响范围，以减少系统损失。
4 事务日志与恢复
4.1 日志记录
日志记录是事务可靠性的基础之一。系统在事务执行过程中，会把关键修改和状态变化写入日志，供后续恢复和审计使用。
4.1.1 写前日志
写前日志要求在数据页真正修改之前，先将相应的日志信息写入稳定存储。这样即使系统突然故障，也能根据日志重建或撤销未完成的操作。
4.1.2 检查点机制
检查点机制用于标记系统恢复时可参考的安全位置。通过定期记录检查点，数据库可以减少故障后需要扫描的日志量，从而提升恢复效率。
4.2 故障恢复
故障恢复是指系统在异常中断后，利用日志和状态信息把数据库恢复到一致状态的过程。它的目标不是简单恢复到某一时刻，而是尽量重建已提交结果并清除未完成修改。
4.2.1 未提交事务恢复
未提交事务恢复通常采用撤销方式，将尚未完成的修改回退。这样可以消除故障前未被正式确认的操作，避免这些内容进入可见数据。
4.2.2 已提交事务恢复
已提交事务恢复则侧重于重做已经确认生效但尚未完全写入数据文件的内容。借助日志，系统能够把提交结果重新应用到数据库中，保证持久性。
4.3 数据回放与重做
数据回放与重做是恢复流程中的常见步骤。回放指按照日志顺序重新执行某些记录，重做则强调把已提交的修改再次施加到目标数据上，以修复故障后可能遗失的部分。
4.4 撤销与补偿操作
撤销用于取消事务已经产生但不应保留的修改；补偿操作则常见于较复杂的业务流程中，用于在部分步骤无法回退时，通过逆向或修正动作实现逻辑补偿。这类机制在长事务和分布式环境中尤为重要。
5 事务模型
5.1 单事务模型
单事务模型描述的是一次只处理一个事务的基本方式。它结构简单，便于理解和验证，适合作为事务系统的理论起点，但在高并发场景下扩展性有限。
5.2 嵌套事务
嵌套事务允许一个事务内部再包含若干子事务。子事务可独立执行部分步骤，并在父事务框架下统一管理。这种结构有助于组织复杂流程，但实现和恢复逻辑更为繁琐。
5.3 分布式事务
分布式事务涉及多个节点或多个数据源协同完成同一逻辑操作。由于参与方分散，系统必须额外处理通信延迟、局部失败和一致性协调等问题。
5.3.1 两阶段提交
两阶段提交是一种常见的分布式提交协议。它先询问各参与方是否准备就绪，再在多数条件满足后正式提交。该协议实现较直观，但在协调者故障时可能出现阻塞。
5.3.2 三阶段提交
三阶段提交在两阶段提交基础上增加了额外阶段，以降低部分阻塞风险。它试图通过更细分的确认流程提升容错能力，但实现成本和系统复杂度也相应提高。
5.4 长事务与短事务
长事务通常运行时间较长，涉及步骤较多，可能跨越多个系统或人工环节；短事务则执行迅速，关注单次原子更新。前者更适合复杂流程，后者更有利于并发与性能。
6 事务的应用场景
6.1 关系型数据库
关系型数据库是事务最典型的应用环境。借助事务，系统可以保证表之间的关联更新保持一致，尤其适合需要严格约束和结构化数据管理的场景。
6.2 金融与支付系统
在金融与支付系统中，事务用于保证资金转移、账务记账和状态更新同步完成。由于这类场景对准确性要求极高，事务往往被视为基础保障机制。
6.3 订单与库存管理
订单系统常需同时处理下单、扣库存、生成记录等多个动作。事务能够防止订单已生成而库存未扣减，或者库存已扣减而订单失败的情况，从而保持业务数据协调。
6.4 工作流与业务流程控制
在工作流系统中，事务可以把多个步骤绑定为可控的执行链。若某一环节失败，系统可依据事务或补偿逻辑恢复到合适状态，减少流程中断带来的影响。
7 事务的性能与优化
7.1 事务开销
事务机制会带来额外开销，包括日志写入、锁管理、版本维护和恢复准备等。这些成本换来了可靠性，但也会影响吞吐量和响应时间。
7.2 事务粒度
事务粒度决定了一个事务包含多少操作。粒度过大容易导致锁持有时间变长、冲突增加；粒度过小则可能使事务数量增多，调度和提交开销上升。实际系统需要在两者之间平衡。
7.3 并发性能优化
提升事务性能通常围绕减少冲突、缩短占用时间和合理选择隔离策略展开。优化目标不是一味追求最高并发，而是在正确性与效率之间取得合适折中。
7.3.1 减少锁竞争
减少锁竞争可以通过缩小访问范围、拆分热点资源或优化访问顺序来实现。降低争用后，多个事务更容易同时推进。
7.3.2 缩短事务时间
缩短事务时间意味着尽快完成事务中的计算和数据访问，并及时提交或回滚。事务持续越久，占用资源的时间越长，也越容易与其他事务发生冲突。
7.3.3 选择合适的隔离级别
不同业务对一致性要求不同。若系统对实时准确性要求较高，可选择较强隔离；若更重视吞吐量，则可在可接受范围内采用较低隔离级别，以减少等待和冲突。
8 事务相关概念辨析
8.1 事务与操作
操作是单个数据动作，如一次查询或一次更新；事务则是多个操作组成的逻辑整体。二者关系类似于“动作”与“流程”，事务强调整体性和结果控制。
8.2 事务与会话
会话表示客户端与数据库之间的一段交互连接，事务则是连接中执行的逻辑单元。一个会话中可以包含多个事务，而一个事务通常隶属于某个会话上下文。
8.3 事务与批处理
批处理强调按批次执行大量任务，重点在效率和自动化；事务强调一组操作的原子性和一致性。批处理可以包含事务，但两者关注点并不相同。
8.4 事务与一致性模型
事务关注的是一组操作在执行过程中的原子提交与回滚；一致性模型则更广泛地描述系统在不同状态下对数据可见性和正确性的要求。事务是实现某些一致性目标的重要工具，但并不等同于全部一致性理论。