理解和使用 PostgreSQL 事务

简介

事务是一种机制，它将多个语句封装到一个数据库处理的单个操作中。数据库不是逐个输入语句，而是能够将语句组解释为一个连贯的单元并对其进行操作。这有助于在许多密切相关的语句过程中确保数据集的一致性。

在本指南中，我们将首先讨论什么是事务以及为什么它们是有益的。之后，我们将看看 PostgreSQL 如何实现事务以及使用事务时可用的各种选项。

什么是事务？

事务 是将多个语句组合在一起并隔离起来，以便作为一个操作进行处理的方法。数据库不是在发送到服务器时单独执行每个命令，而是在事务中，命令被捆绑在一起并在与其他请求不同的上下文中执行。

隔离是事务的重要组成部分。在事务中，执行的语句只能影响事务本身的环境。从事务内部，语句可以修改数据，结果会立即显示。从外部，直到事务提交，才不会进行任何更改，此时事务中的所有操作将同时变得可见。

这些特性有助于数据库通过提供 原子性（事务中的操作要么全部提交，要么全部回滚）和 隔离性（在事务外部，直到提交，否则不会有任何更改，而在事务内部，语句会有影响）来实现 ACID 兼容性。这些特性共同帮助数据库维护 一致性（通过保证不会发生部分数据转换）。此外，直到更改提交到非易失性存储中，事务中的更改才会被视为成功，这提供了 持久性。

为了实现这些目标，事务采用了多种不同的策略，不同的数据库系统使用不同的方法。PostgreSQL 使用称为 多版本并发控制 (MVCC) 的系统，该系统允许数据库在不使用不必要的锁定的情况下使用数据快照执行这些操作。总而言之，这些系统构成了现代关系型数据库的基础基石之一，使它们能够以抗崩溃的方式安全地处理复杂数据。

一致性失败类型

人们使用事务的一个原因是为了获得关于其数据的一致性及其处理环境的某些保证。一致性可以通过多种方式被破坏，这会影响数据库如何尝试防止它们。

根据事务的实现，有四种主要的不一致性出现方式。您对这些场景可能出现的容忍度会影响您在应用程序中使用事务的方式。

事务隔离级别

事务并非“一刀切”的解决方案。不同的场景需要在性能和保护之间进行权衡。幸运的是，PostgreSQL 允许您指定所需的事务隔离类型。

大多数数据库系统提供的隔离级别包括以下几种：

定义事务

现在我们已经介绍了 PostgreSQL 在事务中使用的不同隔离级别，让我们演示如何定义事务。

在 PostgreSQL 中，每个在显式标记的事务之外的语句实际上都在自己的单个语句事务中执行。要显式启动事务块，可以使用BEGIN或START TRANSACTION命令（它们是同义词）。要提交事务，请发出COMMIT命令。

因此，事务的基本语法如下所示：

BEGIN;

statements

COMMIT;

作为一个更具体的例子，想象一下，我们正在尝试将 1000 美元从一个账户转到另一个账户。我们希望确保这笔钱始终在两个账户中的一个账户里，而不会同时出现在两个账户里。

我们可以将一起封装此转账的两个语句包装在一个类似于以下所示的事务中：

 BEGIN;

UPDATE accounts
   SET balance = balance - 1000
 WHERE id = 1;

UPDATE accounts
   SET balance = balance + 1000
 WHERE id = 2;

COMMIT;

在此，不会在没有将 1000 美元存入id = 2的账户的情况下，从id = 1的账户中取出 1000 美元。虽然这两个语句在事务内部按顺序执行，但它们将同时提交，因此在底层数据集中执行。

回滚事务

在事务中，所有语句要么全部提交到数据库，要么都不提交。放弃事务中执行的语句和修改，而不是将它们应用到数据库，被称为“回滚”事务。

事务可以自动或手动回滚。如果事务中的某个语句导致错误，PostgreSQL 会自动回滚事务。如果选定的隔离级别不允许序列化错误，PostgreSQL 也会回滚事务。

要手动回滚当前事务中执行的语句，可以使用ROLLBACK命令。这将取消事务中的所有语句，本质上将时间倒回到事务开始时。

例如，假设我们使用之前使用的相同银行账户示例，如果我们在发出UPDATE语句后发现错误地转账了错误的金额或使用了错误的账户，我们可以回滚更改，而不是提交它们：

   BEGIN;

  UPDATE accounts
     SET balance = balance - 1500
   WHERE id = 1;

  UPDATE accounts
     SET balance = balance + 1500
   WHERE id = 3;  -- Wrong account number here!  Must rollback

/* Gets us back to where we were before the transaction started */
ROLLBACK;

在我们ROLLBACK之后，1500 美元将仍然在id = 1的账户中。

在回滚时使用保存点

默认情况下，ROLLBACK命令将事务重置为首次调用BEGIN或START TRANSACTION命令时的状态。但是，如果我们只想撤消事务中的某些语句，该怎么办？

虽然在执行 ROLLBACK 命令时无法指定任意回滚点，但您可以回滚到事务中设置的任何“保存点”。您可以使用 SAVEPOINT 命令预先标记事务中的位置，并在需要回滚时引用这些特定位置。

这些保存点允许您创建一个中间回滚点。然后，您可以选择性地撤消从当前位置到保存点之间执行的任何语句，然后继续处理您的事务。

要指定保存点，请执行 SAVEPOINT 命令，后跟保存点的名称。

SAVEPOINT save_1;

要回滚到该保存点，请使用 ROLLBACK TO 命令。

ROLLBACK TO save_1;

让我们继续我们一直在使用的以帐户为中心的示例。

    BEGIN;

   UPDATE accounts
      SET balance = balance - 1500
    WHERE id = 1;

/* Set a save point that we can return to */
SAVEPOINT save_1;

   UPDATE accounts
      SET balance = balance + 1500
    WHERE id = 3;  -- Wrong account number here!  We can rollback to the save point though!

/* Gets us back to the state of the transaction at `save_1` */
 ROLLBACK TO save_1;

/* Continue the transaction with the correct account number */
   UPDATE accounts
      SET balance = balance + 1500
    WHERE id = 4;

   COMMIT;

在这里，我们能够从错误中恢复，而不会丢失迄今为止在事务中完成的所有工作。回滚后，我们将继续使用正确的语句按计划执行事务。

设置事务的隔离级别

要设置事务所需的隔离级别，可以在 START TRANSACTION 或 BEGIN 命令中添加 ISOLATION LEVEL 子句。基本语法如下所示。

BEGIN ISOLATION LEVEL <isolation_level>;

statements

COMMIT;

<isolation_level> 可以是以下任何一个（前面已详细描述）。

• READ UNCOMMITTED（将导致 READ COMMITTED，因为 PostgreSQL 中未实现此级别）。
• READ COMMITTED
• REPEATABLE READ
• SERIALIZABLE

SET TRANSACTION 命令也可以在事务启动后用于设置隔离级别。但是，只能在执行任何查询或数据修改命令之前使用 SET TRANSACTION，因此它不提供更高的灵活性。

链接事务

如果有多个事务应按顺序执行，可以选择使用 COMMIT AND CHAIN 命令将它们链接在一起。

COMMIT AND CHAIN 命令通过提交其中的语句来完成当前事务。提交处理完成后，它会立即打开一个新事务。这允许您将另一组语句分组在一个事务中。

该语句的工作方式与执行 COMMIT; BEGIN 相同。

    BEGIN;

   UPDATE accounts
      SET balance = balance - 1500
    WHERE id = 1;

   UPDATE accounts
      SET balance = balance + 1500
    WHERE id = 2;

/* Commit the data and start a new transaction that will take into account the committed from the last transaction */
   COMMIT AND CHAIN;

   UPDATE accounts
      SET balance = balance - 1000
    WHERE id = 2;

   UPDATE accounts
      SET balance = balance + 1000
    WHERE id = 3;

   COMMIT;

链接事务在功能方面没有太多优势，但它可以帮助在自然边界处提交数据，同时继续专注于相同类型的操作。

结论

事务不是灵丹妙药。各种隔离级别带来了很多权衡，了解需要保护哪些类型的一致性需要思考和计划。对于长时间运行的事务来说尤其如此，因为底层数据可能会发生重大变化，与其他并发事务发生冲突的可能性也会增加。

尽管如此，事务机制提供了很大的灵活性和强大功能。它在很大程度上确保了即使在执行相互关联的并发操作时也能维护 ACID 保证。了解何时以及如何正确使用事务来执行复杂的安全操作非常宝贵。