将 300 卢比从 Asha 转移到 Ben 需要两次更新：从一个帐户中减去并添加到另一个帐户中。如果他们之间的系统出现故障，金钱就会消失。 SQL 事务 的存在就是为了使这成为不可能，通过将这两个步骤视为一个单元。

在本指南中，我们将在一个小帐户表上运行提交、回滚和失败。我们在 SQLite 中运行这些示例，显示的余额来自该运行。跨数据库的基本命令相似，但锁定和隔离行为差异很大，因此我们指出在哪里查看您自己的数据库文档。

什么是交易？

事务是数据库将其视为单个逻辑操作的一系列一个或多个 SQL 语句。这是我们的桌子：

CREATE TABLE accounts (
  id INT PRIMARY KEY,
  owner TEXT,
  balance INT CHECK (balance >= 0)
);

INSERT INTO accounts VALUES (1, 'Asha', 1000), (2, 'Ben', 200);

CHECK 约束是余额永远不能低于零的规则，我们稍后将使用它。请注意，开始事务的语法有所不同：SQLite 和 PostgreSQL 接受 BEGIN，MySQL 也有 START TRANSACTION，而 SQL Server 使用 BEGIN TRANSACTION。

在显式事务之外，大多数数据库使用 自动提交，其中每个语句在完成后立即保存。 Oracle 是一个值得注意的例外，因为那里的会话一直保留在事务中，直到您提交为止。

COMMIT：使其永久化

BEGIN;
UPDATE accounts SET balance = balance - 300 WHERE id = 1;
UPDATE accounts SET balance = balance + 300 WHERE id = 2;
COMMIT;

-- Asha | 700
-- Ben  | 500

在 COMMIT 运行之前，这些更改都是临时的。一旦成功返回，数据库保证它们被保存。两个账户的总金额保持在 1200，这就是本次活动的重点。

ROLLBACK：取消一切

ROLLBACK 撤消自事务开始以来的所有操作：

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
SELECT owner, balance FROM accounts;
-- Asha | 600   (visible inside this transaction)
-- Ben  | 500

ROLLBACK;
SELECT owner, balance FROM accounts;
-- Asha | 700   (back to where it was)
-- Ben  | 500

如果在提交之前连接断开或服务器崩溃，回滚也会自动发生，因此半完成的事务将无法生存。

当语句失败时

这是一个更现实的案例。 Asha 尝试发送 5000，但该帐户不持有该金额。 Ben 的贷方首先运行，然后借方打破了 CHECK 规则：

BEGIN;
UPDATE accounts SET balance = balance + 5000 WHERE id = 2;
UPDATE accounts SET balance = balance - 5000 WHERE id = 1;
-- error: CHECK constraint failed: balance >= 0

ROLLBACK;

-- Asha | 700
-- Ben  | 500

如果没有这笔交易，本就会保留这 5000 美元，账簿就会出错。请注意一个重要细节：失败的语句并不总是会自行取消事务。例如，在 SQLite 和 MySQL 中，较早的语句可能保持挂起状态，因此您的代码必须发出回滚。相反，PostgreSQL 将整个事务标记为已中止，并拒绝进一步的语句，直到您回滚。

在应用程序代码中，始终将事务与错误处理配对。这是 Python 中的想法，我们的 Python 异常处理 指南解释了语法：

try:
    conn.execute("BEGIN")
    conn.execute(debit_sql, values)
    conn.execute(credit_sql, values)
    conn.execute("COMMIT")
except Exception:
    conn.execute("ROLLBACK")
    raise

保存点

保存点标记事务内的位置，因此您只能撤消部分工作：

BEGIN;
UPDATE accounts SET balance = balance - 50 WHERE id = 1;
SAVEPOINT bonus;
UPDATE accounts SET balance = balance + 999 WHERE id = 2;
ROLLBACK TO bonus;
UPDATE accounts SET balance = balance + 50 WHERE id = 2;
COMMIT;

-- Asha | 650
-- Ben  | 550

999 奖金被撤销，而其余交易继续进行并已提交。这对于长流程中的可选步骤很有用。

ACID 属性解释

一致性常常被误解。数据库仅强制执行您声明的规则，例如约束和外键。它不会阻止您的代码转移错误的金额。持久性通常通过预写日志来实现，其中在确认提交之前将更改安全地记录在磁盘上。

并发事务会发生什么？

我们打开了到一个 SQLite 文件的两个连接。第一个启动了一个事务并将一行从 1 更新为 2，但尚未提交。这是第二个连接看到的内容：

Connection B reads:   1                     -- no uncommitted data
Connection B writes:  database is locked    -- it has to wait
(A commits)
Connection B reads:   2                     -- now it sees the change

SQLite 一次只允许一名写入者，这比服务器数据库更简单，在服务器数据库中，许多事务可以同时写入不同的行。但原理是一样的：正常设置下其他会话不应该看到未提交的更改，冲突的写入必须等待。在我们的测试中，我们将第二个连接设置为立即放弃而不是等待，因此错误立即出现。

读取异常

当事务重叠时，可能会出现某些问题。 SQL 标准根据事务可能观察到的内容定义了这些：

另一个问题是丢失更新。两个会话读取余额为 100，每个会话添加 10，每个会话写入 110。当答案应该是 120 时，一次更新实际上已经消失。

SQL 隔离级别

隔离级别让您可以用严格性换取并发性。以下是 SQL 标准在每个级别允许的内容：

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

确切的语法和行为取决于您的数据库。默认值也不同：PostgreSQL 和 SQL Server 使用已提交读，而 MySQL 的 InnoDB 使用可重复读。有些数据库提供比标准要求更强的保证，或者将一个级别视为另一级别。例如，在 PostgreSQL 中，未提交读的行为类似于已提交读。在依赖特定行为之前，请务必阅读数据库的文档。

僵局

当两个事务各自持有另一个事务所需的锁时，就会发生死锁。事务 A 锁定第 1 行并想要第 2 行，而事务 B 锁定第 2 行并想要第 1 行。两者都无法继续。

PostgreSQL、MySQL 和 SQL Server 等数据库会检测到这一情况并取消一个错误事务。这是正常行为，您的应用程序应该为此做好准备。为了减少死锁，请始终以一致的顺序更新行，例如首先更新最低帐户 ID，保持事务简短，并在选择一个受害者时重试。

最佳实践

• 保持事务简短。长事务持有锁并阻止其他用户。
• 永远不要在事务中等待用户或缓慢的 API。 在开始之前或之后完成这项工作。
• 始终处理失败。 每个路径都应以提交或回滚结束。
• 添加约束。它们为数据库提供了要强制执行的真正规则。良好的表格设计也有帮助。
• 使用良好的索引。更快的查找意味着锁定的持有时间更短。
• 重试时要小心。 发生死锁时重试，但确保一个操作不能应用两次。
• 有意测试并发性。 其中许多错误仅在负载下出现，因此仅靠基本的集成测试可能无法揭示它们。

最后的话

事务将几个有风险的步骤转化为一个安全的操作，ACID 描述了使这一过程值得信赖的保证。每当一项业务操作涉及多个行或表时，问问自己如果它中途停止会发生什么。如果答案让您担心，请将其包装在交易中。要进行练习，请在本地数据库中打开两个会话并尝试自己产生异常。

常见问题

继续学习