当前位置：首页 > news >正文

数据库事务（Transaction）的概念及其底层实现原理

news 2025/9/29 17:23:29

数据库事务（Transaction）的概念及其底层实现原理

事务（Transaction）是一个非常核心的数据库概念。我将从概念、特性、原理三个方面来详细解释。

第一部分：数据库事务操作是什么？

1. 定义

事务（Transaction）是数据库管理系统（DBMS）执行过程中的一个逻辑单位，由一个有限的数据库操作序列构成。这些操作要么全部执行，要么全部不执行，是一个不可分割的工作单元。

2. 一个经典例子：银行转账

假设你要从账户A转账100元到账户B。这个操作包含两个步骤：

从账户A的余额中减去100元。
向账户B的余额中增加100元。

如果没有事务，可能会发生这样的情况：步骤1执行成功后，数据库突然宕机，步骤2没有执行。结果是，账户A的钱少了，但账户B的钱没收到，这100元就“消失”了。

如果使用事务，这两个步骤将被捆绑在一起。要么两步都成功完成（提交），要么在任何一个步骤失败时，两步都撤销（回滚）。这样就能保证资金不会凭空消失或产生。

3. 事务的四大特性（ACID）

事务必须满足ACID特性，这是事务的基石。

A - 原子性（Atomicity）
- 含义：事务被视为一个不可分割的最小单元，事务中的所有操作要么全部提交成功，要么全部失败回滚。
- 类比：原子是化学反应中的最小单位。事务就像原子一样，不可再分。
- 实现机制：通过 Undo Log（回滚日志）实现。
C - 一致性（Consistency）
- 含义：事务的执行必须使数据库从一个一致性状态转变到另一个一致性状态。一致性状态是指数据满足预定义的约束（如唯一约束、外键约束、业务规则等）。
- 注意：一致性是事务的最终目标，原子性、隔离性和持久性都是为了实现一致性而存在的手段。
- 银行转账例子：转账前后，两个账户的总金额应该保持不变（A+B = (A-100)+(B+100)）。
I - 隔离性（Isolation）
- 含义：一个事务的执行不应受其他并发执行的事务的干扰。在并发环境下，多个事务同时执行，其效果应与它们串行执行一样。
- 现实：完全的隔离性会严重影响性能，因此数据库提供了不同级别的隔离级别供用户权衡。
- 实现机制：通过锁机制和 MVCC（多版本并发控制） 实现。
D - 持久性（Durability）
- 含义：一旦事务提交，它对数据库的修改就是永久性的，即使发生系统故障（如断电、宕机），数据也不会丢失。
- 实现机制：通过 Redo Log（重做日志）实现。

第二部分：底层实现原理

ACID特性的实现，依赖于日志系统和并发控制技术。

1. 如何实现原子性（Atomicity）和持久性（Durability）？—— Undo Log 和 Redo Log

这是通过预写日志（Write-Ahead Logging, WAL） 机制来保障的。核心思想是：在数据页被修改之前，先将修改内容记录到日志中。

Redo Log（重做日志）
- 作用：保证事务的持久性。
- 内容：记录的是事务对数据页的物理修改（例如：“在表空间5，页号10，偏移量20的位置写入值‘xxx’”）。
- 工作流程：
  1. 事务开始时，就会开始记录Redo Log。
  2. 在修改内存中的数据页之前，先将修改操作记录到Redo Log Buffer（重做日志缓冲区）中。
  3. 在事务提交时，必须将Redo Log Buffer中的相关日志强制刷入（fsync）磁盘的Redo Log文件。这是事务提交的关键一步。
  4. 之后，DBMS才在合适的时机将内存中脏数据页刷新到磁盘的数据文件中。
- 崩溃恢复：当数据库崩溃重启时，会检查Redo Log，将那些已经提交但尚未写入数据文件的事务（记录在Redo Log中）重新执行一遍，从而保证已提交事务的持久性。
Undo Log（回滚日志）
- 作用：保证事务的原子性和隔离性（MVCC的实现依赖Undo Log）。
- 内容：记录的是事务发生之前的数据旧版本（例如：“在修改前，该行的值是‘yyy’”）。
- 工作流程：
  1. 在事务修改某行数据之前，先将该数据的原始版本复制到Undo Log中。
  2. 如果事务需要回滚（例如，执行了ROLLBACK或事务中途失败），DBMS就可以利用Undo Log中的记录，将数据恢复到事务开始前的状态。
  3. 如果事务成功提交，Undo Log中的记录也不会立即删除，因为它可能还被其他并发事务所使用（用于实现MVCC的读一致性视图），会在不再被需要时由后台进程清理。

总结关系：

Redo Log 是为了重放已提交的操作，解决提交后，刷盘前的崩溃问题。
Undo Log 是为了回滚未提交的操作，解决提交前的失败或主动回滚问题。

2. 如何实现隔离性（Isolation）？—— 锁与 MVCC

并发事务可能导致脏读、不可重复读、幻读等问题。为了解决这些问题，数据库采用了两种主要技术：

锁机制（Locking）
- 原理：一种悲观的并发控制。事务在访问数据前先加锁，防止其他事务同时修改，从而保证串行化。
- 类型：
  - 共享锁（S Lock）：读锁，允许其他事务读，但不允许写。
  - 排他锁（X Lock）：写锁，不允许其他事务读或写。
- 粒度：行锁、表锁、页锁等。现代数据库（如MySQL InnoDB）主要使用行级锁来保证高并发。
多版本并发控制（MVCC）
- 原理：一种乐观的并发控制。它通过保存数据的多个历史版本来实现非阻塞的读操作，极大提升了并发性能。这是现代数据库（如MySQL InnoDB, PostgreSQL）的默认选择。
- 核心组件：
  1. 事务ID（Transaction ID）：每个事务开始时都会被分配一个唯一且递增的ID。
  2. 隐藏的版本字段：
    - DB_TRX_ID：记录创建或最后一次修改该行数据的事务ID。
    - DB_ROLL_PTR：回滚指针，指向该行数据在Undo Log中的上一个历史版本。
    - DB_ROW_ID：隐含的自增行ID（如果表没有主键）。
  3. Read View（读视图）：在事务执行快照读（普通的SELECT）时，会生成一个Read View，其中记录了当前系统中所有活跃（未提交）事务的ID列表。
- 工作流程（以可重复读为例）：
  1. 当事务A发起一个SELECT查询时，会创建一个Read View。
  2. 当遍历到某一行数据时，检查该行数据的DB_TRX_ID。
  3. 如果DB_TRX_ID小于Read View中的最小活跃事务ID，说明该行数据在事务A开始前就已提交，是可见的。
  4. 如果DB_TRX_ID大于等于Read View中的最大活跃事务ID，说明该行数据是在事务A开始之后才被修改的，是不可见的。此时需要通过DB_ROLL_PTR找到Undo Log中的历史版本，并判断该历史版本是否对当前事务可见。
  5. 如果DB_TRX_ID在活跃事务ID列表中，说明该行数据是由尚未提交的事务修改的，是不可见的，同样需要查找Undo Log中的历史版本。
  6. 通过这种方式，事务A在整个过程中，总能读取到同一条数据在它开始之前就已经提交的那个版本，从而实现了可重复读。

总结

特性	目标	核心实现机制
原子性 (A)	全部成功或全部失败	Undo Log
一致性 ( C )	数据符合约束和逻辑	由A、I、D共同保证，是最终目标
隔离性 (I)	并发事务互不干扰	锁机制、MVCC（依赖Undo Log）
持久性 (D)	提交后数据不丢失	Redo Log（WAL机制）