数据库事务是关系型数据库最核心的能力之一，也是现代应用系统实现数据一致性的基础设施。理解事务的工作原理，不仅是 CRUD 操作的基础，更是构建可靠业务逻辑的关键。本文将从原子性出发，逐步展开事务的完整生命周期，并探讨隔离性如何在实际开发中影响数据可见性与并发性能。
事务的定义与原子性保证
事务本质上一组数据库操作的逻辑容器，它将多个 SQL 语句封装为单一原子执行单元。在 MySQL 和 PostgreSQL 中，开发者通过 BEGIN 或 START TRANSACTION 显式开启事务，随后执行任意数量的查询（SELECT、INSERT、UPDATE、DELETE），最终以 COMMIT 提交使所有变更永久生效，或以 ROLLBACK 回滚使所有变更如从未发生。这一「全有或全无」的语义即为事务的原子性（Atomicity）保证。
原子性的工程意义在于：它将一组相关操作视为不可分割的整体。以典型的转账场景为例，从账户 A 扣款与向账户 B 存款必须同时成功或同时失败，任何中间状态（如仅扣款未存款）都不应对外可见。事务正是通过将这两个 UPDATE 语句纳入同一执行单元，确保了业务层面的数据一致性。值得注意的是，原子性的实现依赖于数据库的灾难恢复机制 —— 当事务执行过程中发生硬件故障或电源中断时，MySQL 和 PostgreSQL 分别通过 redo log 与 WAL（Write-Ahead Logging）机制在系统恢复后完成事务的提交或回滚，从而保证持久性不受损。
事务生命周期与三大核心命令
事务的生命周期遵循「开启 — 执行 — 结束」的模式。BEGIN 命令创建事务上下文，此后所有 SQL 语句都在该上下文中执行，彼此共享同一隔离视图，直至明确结束。COMMIT 的执行标志着事务的正式完成：数据库将此前所有修改从缓冲区刷入磁盘，对其他会话可见，同时释放事务占用的资源。ROLLBACK 则用于主动撤销 —— 无论是由于业务校验失败、用户主动取消，还是语句执行错误，数据库都会利用 undo log（MySQL）或多版本链（PostgreSQL）恢复数据至事务开始时的状态。
在应用代码中，事务的正确使用通常遵循固定模式：首先建立数据库连接并开启事务，然后执行一条或多条查询，随后检查是否存在错误，最后根据检查结果调用 COMMIT 或 ROLLBACK。以 Node.js 为例，使用 planetscale/database-js 或 mysql2 驱动时，典型代码结构为「beginTransaction () → 执行查询 → commit () /rollback ()」，任何异常都应触发回滚以防止连接泄漏。这种模式看似简单，却是避免数据不一致的第一道防线。
隔离性与一致读的实现机制
事务的核心价值不仅在于原子性，更在于隔离性（Isolation）—— 它允许多个事务并发执行而互不干扰。隔离性的实现依赖于「一致读」（Consistent Read）机制：事务执行期间应看到数据库的某个稳定快照，不受其他并发事务的未提交或已提交变更影响。这一机制在 MySQL 和 PostgreSQL 中有截然不同的实现方式。
PostgreSQL 采用多行版本控制（Multi-Version Concurrency Control, MVCC），每次 INSERT 或 UPDATE 都创建新行版本并保留旧版本，通过 xmin（创建行的事务 ID）和 xmax（删除或替换该行的事务 ID）元数据判断各事务应看到哪个版本。MySQL（InnoDB 引擎）则采用 undo log 策略：行数据被直接覆盖，但旧值被记录在 undo log 中，需要时可通过日志重建历史版本。两种方案各有权衡 ——PostgreSQL 需要定期运行 VACUUM 清理过期版本以回收空间，而 MySQL 的 undo log 需要维护但避免了版本膨胀。
隔离级别与并发现象
SQL 标准定义了四个隔离级别，从强到弱依次为：SERIALIZABLE（可串行化）、REPEATABLE READ（可重复读）、READ COMMITTED（已提交读）和 READ UNCOMMITTED（未提交读）。隔离级别越高，对并发问题的防护越严格，但性能代价也越大。理解这些级别对应的异常现象，是做出正确工程决策的前提。
脏读（Dirty Read）是最严重的异常 —— 一个事务能看到另一个未提交事务的修改。在 READ UNMITTED 级别下可能发生，工程项目中应坚决避免。不可重复读（Non-Repeatable Read）指同一事务内两次读取同一行数据，得到不同结果，因为另一事务在该间隙提交了修改 ——READ COMMITTED 允许此现象。幻读（Phantom Read）则指同一事务内两次执行相同范围查询，结果集行数不同，因为另一事务在该间隙插入了新行 ——REPEATABLE READ 按 SQL 标准允许幻读，但 PostgreSQL 凭借其 MVCC 实现实际上避免了幻读。
实际工程中，READ COMMITTED 是大多数应用的默认选择，因为它在数据一致性与性能之间取得合理平衡。REPEATABLE READ 适用于需要更强一致性保证的业务场景，但需要留意锁竞争可能带来的吞吐量下降。SERIALIZABLE 则要求最高的一致性保障，通过复杂的锁机制或乐观冲突检测确保事务如顺序执行般正确，但可能导致更多事务被终止并需要应用层重试。
并发写入的冲突处理
当两个事务同时修改同一行数据时，冲突处理策略取决于数据库实现与隔离级别。在 SERIALIZABLE 隔离级别下，MySQL 采用行级锁机制：共享锁（S Lock）允许多事务同时读取，而排他锁（X Lock）独占写权限且互斥。事务在修改行前必须获得 X Lock，若另一事务已持有该锁则等待。若形成循环等待（死锁），MySQL 能检测并终止其中一个事务以打破僵局。
PostgreSQL 的 SERIALIZABLE 隔离级别则采用不同的思路 —— 可串行化快照隔离（SSI）。它通过谓词锁（Predicate Lock）追踪事务访问的行集，而非直接阻塞读操作。当事务提交时，PostgreSQL 检测是否存在与已提交事务的读写冲突，若存在则终止当前事务并抛出序列化失败错误。这种乐观并发控制策略避免了死锁，但要求应用代码具备事务重试能力来处理被终止的情况。
工程实践建议
在实际项目中使用数据库事务时，有几个关键实践值得关注。首先，事务范围应尽可能短 —— 将不必要的查询纳入事务会增加锁持有时间，降低系统吞吐量。其次，严格区分业务层面的错误与数据库错误：业务校验失败应主动回滚，而非依赖异常捕获后再回滚。第三，明确选择合适的隔离级别 —— 除非有特殊需求，否则无需使用 SERIALIZABLE。最后，为所有关键事务实现重试机制，特别是使用 PostgreSQL 时，因为 SSI 策略可能导致事务被主动终止。
事务是数据库系统为开发者提供的基础抽象，它将底层的并发控制、崩溃恢复、版本管理封装为简单的 BEGIN/COMMIT/ROLLBACK 接口。理解这些概念的工作原理与权衡，是写出健壮数据访问代码的必经之路。
资料来源：本文核心概念与示例参考 PlanetScale 博客文章《Database Transactions》（2026 年 1 月），该文详细阐述了 MySQL 与 PostgreSQL 事务机制的差异与实现原理。