如何轻松掌握数据库事务？

事务的核心：ACID特性

1. 原子性（Atomicity）
   事务的所有操作要么全部成功，要么全部失败回滚，例如银行转账：A账户扣款和B账户入款必须同时成功或同时撤销。

   

   • 实现方式：通过事务日志（Transaction Log）记录操作,失败时按日志反向回滚。

2. 一致性（Consistency）
   事务执行后，数据库必须满足所有预设规则（如外键约束、唯一索引）。

3. 隔离性（Isolation）
   并发事务互不干扰，通过隔离级别控制（见下文）。

4. 持久性（Durability）
   事务提交后，修改永久保存，依赖预写日志（WAL）技术：数据写入前先记录日志,确保故障后可恢复。

事务控制的关键操作

手动控制事务（以SQL为例）

BEGIN TRANSACTION; -- 开始事务
UPDATE accounts SET balance = balance - 100 WHERE user_id = 'A';
UPDATE accounts SET balance = balance + 100 WHERE user_id = 'B';
-- 检查业务逻辑是否成功
IF @@ERROR = 0 
    COMMIT TRANSACTION; -- 提交事务
ELSE
    ROLLBACK TRANSACTION; -- 回滚事务

保存点（Savepoint）

允许部分回滚到事务中的特定节点：

SAVEPOINT savepoint1;
INSERT INTO orders (...) VALUES (...);
-- 若后续操作失败，仅回滚到保存点
ROLLBACK TO savepoint1;

事务隔离级别与并发控制

不同隔离级别解决并发问题：
| 隔离级别 | 脏读 | 不可重复读 | 幻读 | 适用场景 |
|———————–|——|————|——|——————————|
| READ UNCOMMITTED | 可能 | 可能 | 可能 | 低一致性需求（极少使用） |
| READ COMMITTED | 避免 | 可能 | 可能 | 默认级别（如PostgreSQL） |
| REPEATABLE READ | 避免 | 避免 | 可能 | 金融交易（MySQL InnoDB默认） |
| SERIALIZABLE | 避免 | 避免 | 避免 | 强一致性（牺牲并发性能） |

• 设置方法：

  SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

编程语言中的事务控制示例

Python（使用psycopg2操作PostgreSQL）

import psycopg2
conn = psycopg2.connect(database="test")
try:
    conn.autocommit = False  # 关闭自动提交
    cursor = conn.cursor()
    cursor.execute("UPDATE accounts SET balance = balance - 100 WHERE id=1")
    cursor.execute("UPDATE accounts SET balance = balance + 100 WHERE id=2")
    conn.commit()  # 提交事务
except Exception as e:
    conn.rollback()  # 失败回滚
finally:
    cursor.close()
    conn.close()

Java（JDBC + Spring注解）

@Transactional(isolation = Isolation.READ_COMMITTED, propagation = Propagation.REQUIRED)
public void transferMoney() {
    jdbcTemplate.update("UPDATE accounts SET balance=balance-100 WHERE id=1");
    jdbcTemplate.update("UPDATE accounts SET balance=balance+100 WHERE id=2");
}
// 抛出异常时自动回滚

最佳实践与常见陷阱

1. 最佳实践

   • 事务尽量短小：减少锁竞争，提升并发性。
   • 明确设置隔离级别：根据业务需求平衡一致性与性能。
   • 异常处理：确保编程中捕获异常并回滚。
   • 避免长事务：监控执行时间，防止锁阻塞（如MySQL的SHOW PROCESSLIST）。

2. 常见错误

   • 未处理异常：导致事务未提交或未回滚（“僵尸事务”）。
   • 过度使用SERIALIZABLE：高并发场景下性能急剧下降。
   • 嵌套事务误解：部分数据库不支持嵌套,需用保存点替代。

高级场景：分布式事务

当操作涉及多个数据库时（如微服务架构），采用两阶段提交（2PC）或Saga模式：

• 2PC：
  协调者（Coordinator）分两阶段管理参与者（Participants）：

  1. 准备阶段：询问所有参与者是否能提交。
  2. 提交阶段：全部同意则提交，任一失败则回滚。

  缺点：同步阻塞,协调者单点故障。

  

• Saga模式：
  将大事务拆分为多个子事务，每个子事务有补偿操作（Compensation）。
  示例：订单创建 → 扣库存 → 支付,失败时反向执行补偿逻辑。

事务控制是数据库系统的基石，正确使用需：

1. 理解ACID原则与隔离级别；
2. 在SQL或代码中显式管理事务边界；
3. 根据业务选择隔离级别和分布式方案；
4. 严格遵循异常处理与性能优化实践。
   通过合理控制事务，可确保数据可靠性,支撑高并发业务场景。

引用说明：

• ACID定义参考自Jim Gray的《事务处理：概念与技术》。
• 隔离级别标准依据ANSI SQL-92规范。
• 分布式事务模型引用了Martin Kleppmann《设计数据密集型应用》。
• 代码示例基于PostgreSQL官方文档及Spring Framework最佳实践。