事务基础：数据库事务的ACID特性、隔离级别与生命周期

事务是数据库系统并发控制与故障恢复的基本单位。理解事务的ACID特性、隔离级别以及完整的生命周期，是构建可靠数据访问层的前提。本章将系统梳理这三个核心维度，为后续连接池水位控制和权限验证打下理论基础。

2.1 事务的ACID特性

ACID是数据库事务正确执行的四个基本特性的缩写，由原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability）组成。任何声称支持事务的数据库系统，都必须保证这四个特性。

特性 核心含义 实现机制 违反后果
原子性 事务中的所有操作要么全部成功提交，要么全部失败回滚，不存在部分执行的状态。 通过 undo log（回滚日志）记录操作前的数据状态，回滚时逆向执行。 部分更新导致数据不一致，例如转账时扣款成功但收款失败。
一致性 事务执行前后，数据库必须从一个一致性状态转换到另一个一致性状态。所有数据约束（主键、外键、唯一索引、业务规则）必须被满足。 由应用层业务逻辑 + 数据库约束共同保证。ACID中的其他三个特性最终服务于一致性。 数据违反业务规则，如订单总金额与明细金额不匹配。
隔离性 并发执行的事务之间互不干扰，每个事务都感觉自己是唯一在运行的。 通过锁机制（行锁、表锁、间隙锁）和 MVCC（多版本并发控制）实现。 脏读、不可重复读、幻读等并发问题。
持久性 一旦事务提交成功，其对数据库的修改就是永久性的，即使系统崩溃也不会丢失。 通过 redo log（重做日志）在事务提交时将修改写入磁盘，崩溃恢复时重放。 已提交的数据在宕机后丢失，违反数据可靠性承诺。
实践要点：在Go应用中，database/sql 包的 Tx 对象默认不保证隔离性——你需要显式设置隔离级别。同时，defer tx.Rollback() 是保证原子性的常见模式，但要注意 Rollback 在已提交事务上调用会返回 ErrTxDone 错误，需要妥善处理。

2.2 事务的隔离级别

SQL标准定义了四种隔离级别，用于平衡并发性能与数据一致性。隔离级别从低到高，并发性能递减，但数据安全性递增。

2.2.1 三种并发读问题

在理解隔离级别之前，必须先掌握三种典型的并发读异常：

  • 脏读（Dirty Read）： 事务A读取了事务B未提交的数据。如果事务B回滚，事务A读到的就是无效数据。
  • 不可重复读（Non-Repeatable Read）： 事务A内两次读取同一行数据，由于事务B在中间更新并提交了该行，导致两次读取结果不一致。重点在于行数据被修改。
  • 幻读（Phantom Read）： 事务A内两次执行相同的范围查询，由于事务B在中间插入并提交了新行，导致第二次查询多出了一些行。重点在于行数发生变化。

2.2.2 四种隔离级别对比

隔离级别 脏读 不可重复读 幻读 实现方式
READ UNCOMMITTED（读未提交） 可能 可能 可能 直接读取最新版本，不加任何锁
READ COMMITTED（读已提交） 避免 可能 可能 使用MVCC，每次查询都读取最新的已提交快照
REPEATABLE READ（可重复读） 避免 避免 可能（InnoDB通过间隙锁避免） 使用MVCC，事务开始时创建一致性快照，整个事务期间使用该快照
SERIALIZABLE（可串行化） 避免 避免 避免 所有读操作加共享锁，写操作加排他锁，完全串行执行
注意：MySQL InnoDB 引擎在 REPEATABLE READ 级别下，通过 间隙锁（Gap Lock） 和 Next-Key Lock 机制，实际上已经能够避免幻读。因此，InnoDB 的 REPEATABLE READ 在大多数场景下提供了接近 SERIALIZABLE 的一致性保证，同时保持了更高的并发性能。这是MySQL默认隔离级别选择 REPEATABLE READ 的原因。

2.2.3 隔离级别与并发性能的关系

隔离级别与并发性能关系 并发性能 高 低 隔离级别 → 数据一致性增强 READ UNCOMMITTED READ COMMITTED REPEATABLE READ SERIALIZABLE 说明：隔离级别越高，数据一致性越强，但锁竞争越激烈，并发性能越低。实际选型需在一致性与性能之间权衡。

2.3 事务的生命周期

一个数据库事务从开始到结束，经历三个关键阶段：开始（Begin）、执行（Execute） 和 结束（Commit / Rollback）。在Go语言中，事务的生命周期通过 database/sql 标准库的 Tx 对象来管理。

2.3.1 事务生命周期流程图

事务生命周期流程图 Begin 开始事务 Execute 执行SQL 成功? Commit 提交 Rollback 回滚 End 事务结束 是 否 关键原则：事务一旦 Commit 或 Rollback 后，不能再执行任何 SQL 操作，必须重新 Begin 新事务。

2.3.2 Go语言中的事务生命周期代码示例

以下代码展示了在Go中如何完整地管理一个事务的生命周期，包括错误处理和资源释放：

// Go事务生命周期完整示例
func transferFunds(db *sql.DB, fromID, toID int, amount float64) error {
    // 1. 开始事务
    tx, err := db.Begin()
    if err != nil {
        return fmt.Errorf("begin transaction failed: %w", err)
    }

    // 2. 确保在函数退出时回滚（如果尚未提交）
    //    注意：如果事务已提交，Rollback 会返回 sql.ErrTxDone，通常忽略
    defer func() {
        if err := tx.Rollback(); err != nil && err != sql.ErrTxDone {
            log.Printf("rollback warning: %v", err)
        }
    }()

    // 3. 执行业务SQL
    // 扣减转出账户余额
    _, err = tx.Exec("UPDATE accounts SET balance = balance - ? WHERE id = ?", amount, fromID)
    if err != nil {
        return fmt.Errorf("debit failed: %w", err)
    }

    // 增加转入账户余额
    _, err = tx.Exec("UPDATE accounts SET balance = balance + ? WHERE id = ?", amount, toID)
    if err != nil {
        return fmt.Errorf("credit failed: %w", err)
    }

    // 4. 提交事务
    if err := tx.Commit(); err != nil {
        return fmt.Errorf("commit transaction failed: %w", err)
    }

    return nil
}
生命周期关键点：
  • Begin： 从连接池获取一个连接，并开启事务。该连接在事务期间被独占，直到 Commit 或 Rollback 后才归还连接池。
  • Execute： 所有 SQL 操作都通过 tx.Exec、tx.Query 等方法执行，这些操作使用事务绑定的连接。
  • Commit / Rollback： 提交或回滚后，事务对象变为无效，连接归还连接池。再次调用 tx.Exec 会返回 sql.ErrTxDone。
  • defer Rollback： 是防止事务泄漏的标准模式。即使中间发生 panic 或忘记处理错误，也能确保连接被释放。

2.4 事务生命周期中的连接池水位影响

事务的生命周期直接决定了连接池中连接的占用时长。一个长时间运行的事务会一直持有连接，导致连接池水位上升，甚至耗尽连接池。理解这一点对于后续章节的连接池水位控制至关重要。

事务阶段 连接池状态 对水位的影响
Begin 从连接池获取一个连接，该连接被标记为“使用中” 可用连接数 -1，水位上升
Execute 连接持续被占用，无法被其他非事务操作使用 水位维持在高位，其他请求可能排队等待连接
Commit / Rollback 连接归还连接池，标记为“空闲” 可用连接数 +1，水位下降
事务泄漏（未Commit/Rollback） 连接被永久占用，无法归还 连接池逐渐耗尽，最终导致 database/sql: connection pool exhausted 错误
避坑指南：在Go中，defer tx.Rollback() 虽然能防止事务泄漏，但如果 Rollback 本身因为网络问题失败，连接可能仍然无法归还。更安全的做法是结合 context.Context 设置超时，确保长时间未提交的事务能被自动取消。例如：ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second); defer cancel(); tx, err := db.BeginTx(ctx, nil)。

2.5 本章小结

  • ACID 是事务的四大基石：原子性保证全有或全无，一致性保证数据合法，隔离性保证并发安全，持久性保证数据不丢。
  • 四种隔离级别 从 READ UNCOMMITTED 到 SERIALIZABLE，数据一致性递增，并发性能递减。MySQL InnoDB 的 REPEATABLE READ 通过间隙锁避免了幻读。
  • 事务生命周期 包括 Begin、Execute、Commit/Rollback 三个阶段。在Go中，必须使用 defer tx.Rollback() 确保资源释放，并优先使用 BeginTx 配合 context.Context 设置超时。
  • 连接池水位 与事务生命周期直接相关：事务持有连接的时间越长，连接池水位越高，系统并发能力越弱。这是后续章节优化连接池配置的核心依据。
← 上一章 📖 返回目录 下一章 →