PostgreSQL的奥秘：深入探究事务与锁的秘密世界

PostgreSQL事务

1. 概述

在数据库系统中，事务（Transaction）是执行数据库操作的最小逻辑单位。它确保了一组操作的完整性和一致性。事务可以通过显式的 BEGIN、COMMIT 和 ROLLBACK 语句块来控制，也可以在自动提交模式（auto commit）下隐式执行单条语句。

在自动提交模式下，每条 SQL 语句都会被视为一个独立的事务执行，默认情况下不需要显式使用 BEGIN 和 COMMIT。当事务执行时，数据库会对其状态进行跟踪，事务可以处于以下几种状态之一：

• IN_PROGRESS: 事务正在执行中。
• COMMITTED: 事务已成功提交，所有的变更都已永久保存。
• ABORTED: 事务已回滚，未对数据库产生影响。

事务是通过隔离机制来保证多个事务并发执行时互不干扰，并确保数据的一致性和可见性。

事务的可见性问题主要体现在“事务隔离级别”上。不同的事务隔离级别会影响事务之间对数据的可见性，尤其是在并发操作的情况下。数据库系统中常见的四种事务隔离级别分别是：

1. 读未提交（Read Uncommitted）：

   • 描述：事务可以看到其他事务尚未提交的修改。
   • 可见性问题：脏读（Dirty Read）。一个事务可能会读取到另一个事务尚未提交的数据，如果该事务最终回滚，读取到的数据就会不正确。
   • 影响：这种隔离级别最低，几乎不进行隔离。

2. 读已提交（Read Committed）：

   • 描述：事务只能看到其他事务已经提交的修改。
   • 可见性问题：不可重复读（Non-repeatable Read）。同一个事务在不同时间读取同一行数据时，可能会看到不同的结果，因为其他事务可能在中途提交了修改。
   • 影响：这是大多数数据库系统的默认隔离级别，可以避免脏读，但可能会导致不可重复读。

3. 可重复读（Repeatable Read）：

   • 描述：事务在其生命周期内看到的某一行数据是一致的，即使其他事务已对该数据进行了修改。
   • 可见性问题：幻读（Phantom Read）。同一个事务在不同时间执行相同的查询时，可能会看到新增的行数据。
   • 影响：解决了不可重复读问题，但无法避免幻读。

4. 可串行化（Serializable）：

   • 描述：事务完全隔离，仿佛所有事务串行执行。事务之间不存在任何并发操作。
   • 可见性问题：无。这是最高的隔离级别，事务之间完全没有并发的可见性问题。
   • 影响：虽然保证了数据的一致性和隔离性，但由于完全串行化执行，性能开销较高。

事务隔离级别与可见性问题的关系

• 脏读（Dirty Read）：事务A读取了事务B尚未提交的数据，如果事务B回滚，事务A将读到错误的数据。这个问题在“读未提交”隔离级别中会发生。
• 不可重复读（Non-repeatable Read）：事务A在不同时间读取同一行数据时，看到不同的结果，因为事务B在此过程中修改并提交了数据。这个问题在“读已提交”隔离级别中会发生。
• 幻读（Phantom Read）：事务A在不同时间执行相同的查询时，看到不同的结果，通常是因为事务B插入了新的数据行。这个问题在“可重复读”隔离级别中会发生。

事务主要解决的是数据的可见性问题，不同的隔离级别决定了一个事务在执行过程中能看到哪些数据的变化。事务本身不直接解决数据冲突问题（例如并发修改同一行数据的冲突），而是通过机制如锁和事务管理来处理。在实际应用中，选择合适的事务隔离级别需要根据具体的业务需求和性能要求来平衡数据的一致性和系统的并发性能。

为了更好地理解事务的行为，我们需要了解事务的四大关键特性：原子性、一致性、隔离性和持久性。

事务的四大特性（ACID）

1. 原子性（Atomicity）: 一个事务要么全部执行，要么全部不执行。如果事务中某个操作失败，整个事务必须回滚，以保持数据库的一致性。

2. 一致性（Consistency）: 事务的执行应该使数据库从一个一致的状态变更到另一个一致的状态。这意味着事务在执行前后，数据库的完整性约束不会被破坏。

   一致性是指系统数据与真实世界状态的完全匹配，但由于恶意修改、硬件故障等原因，数据库本身无法完全保证一致性，因此需要从应用到存储的端到端协同保障。

   尽管数据库无法从根本上保证数据和真实世界的完全一致，但有一些方法可以提高一致性的保证程度：
   1. 事务机制：数据库通过事务（Transaction）机制来保证数据的一致性。事务具有原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability），即所谓的 ACID 特性。虽然事务无法防止恶意修改或硬件故障，但它可以确保在正常操作中，数据保持一致的状态。
   2. 数据校验和冗余：通过数据校验和冗余（如 RAID 或多副本存储等）可以在一定程度上防止数据损坏或丢失，从而提高一致性。
   3. 加密和访问控制：通过加密和严格的访问控制，可以防止恶意用户篡改数据库中的数据。
   4. 数据修订和审计：通过日志记录、审计跟踪和版本控制，可以追踪数据的变化，发现并纠正不一致的问题。

   端到端的一致性保证: 单靠数据库无法独立保证一致性，整个系统需要从多个层面进行考虑，包括：
   1. 应用层的逻辑：应用层应当对业务规则进行验证，确保写入数据库的数据是正确的。
   2. 网络层的可靠性：在分布式系统中，网络传输的可靠性对数据一致性至关重要。
   3. 用户输入的校验：系统应当对用户输入进行合理的校验，防止不合法的数据进入数据库。
   4. 数据同步机制：对于多个系统或服务之间的数据同步，必须有合适的机制来保证一致性，例如使用分布式事务或事件驱动架构。

3. 隔离性（Isolation）: 事务的隔离性确保了并发执行的事务不会相互干扰。每个事务的执行结果不受其他事务的影响，仿佛它是独立地执行的。

4. 持久性（Durability）: 事务一旦提交，其对数据库的更改应永久保存，即使系统发生故障，也不会丢失已提交的结果。

2. 事务标识（Transaction ID）

在 PostgreSQL 中，每个事务都有一个唯一的标识符，称为事务 ID（Transaction ID，简称 TXID）。TXID 是一个 32 位的无符号整数，取值范围约为 42 亿。为了防止 TXID 空间耗尽，PostgreSQL 使用环形结构管理 TXID。

事务 ID 的分配

PostgreSQL 不会在 BEGIN 语句时立即分配事务 ID，而是在事务执行第一条命令时才会分配 TXID。因此，事务的 TXID 是延迟分配的。用户可以通过 SELECT txid_current() 查询当前事务的 TXID。

PostgreSQL 使用环形结构管理 TXID，以防止 TXID 空间耗尽。由于 TXID 是 32 位整数，其取值范围约为 42 亿。随着事务的不断执行，TXID 会循环使用。

特殊的 TXID

PostgreSQL 保留了以下三个特殊的 TXID：

• TXID 0: 表示无效的 TXID。

• TXID 1: 表示初始化事务，在数据库集群初始化时使用。

• TXID 2: 表示冻结的 TXID，用于标识冻结的元组。冻结元组对所有事务都可见，通常用于回收旧的 TXID。

• 事务 ID 是环形的，当 ID 达到最大值2^32 -1后会绕回到 0。

• 事务 ID 的可见性
  在 PostgreSQL 中，事务之间的可见性通过事务 ID 来决定：

  当前事务只能看到已经提交并且事务 ID 小于当前事务 ID 的那些事务（即过去的事务）。
  当前事务看不到事务 ID 大于自己的事务（即未来的事务），因为那些事务还没有提交。

图例解释：
我们可以把 PostgreSQL 的事务 ID 想象成一个时钟上的数字，比如从0到42亿（实际上是一个32位无符号整数的取值范围）。当事务 ID 增加到最大值后，它会回到 0，重复使用这些 ID，就像时钟的指针回到 12 点一样。

1. 环形结构中的事务 ID
   在图中，事务 ID 是以环形排列的。假设当前事务 ID 是2^31 + 100，那么：

   其后2^31 个事务Id，既图中past部分（从2^31 + 100 - 2^31 + 1 = 101 到 2^31 + 99）为更早的事务，属于过去。

   其前2^31 个事务Id，既图中future部分(从2^31 + 101 ~ 2^32 -1)为更早的事务，属于未来。

2. 当前事务 ID 是2^31 + 101，那么：

   其后2^31 个事务Id，既图中past部分（从101 到 2^31 + 100）为更早的事务，属于过去。

   其前2^{31个事务Id，既图中future部分(从2}31 + 101 ~ 2^32 -1)为更早的事务，属于未来。

那么，事务id总有用完的时候，如果保证事务Id被重新利用，PostgreSQL引入了事务冻结的概念：
事务冻结（Transaction Freezing）

事务 ID 环形结构的一个挑战在于，当事务 ID 回卷到较小的值时，旧的事务 ID 可能会与新的事务 ID 产生冲突。为了解决这个问题，PostgreSQL 使用了“事务冻结”机制。

• 什么是事务冻结？

  当元组（行）的 xmin 或 xmax 事务 ID 非常老时，PostgreSQL 会将其标记为“冻结”状态，通常是将事务 ID 设置为 FrozenXID = 2。这意味着该事务在所有活跃的事务中都已经被认为是可见的，不会再引发可见性冲突。

• 冻结的时机

  冻结通常发生在 VACUUM 操作期间。VACUUM 会扫描表中的老旧元组，判断它们是否可以冻结。如果某个元组的事务 ID 足够老，且已对所有当前和未来事务可见，VACUUM 将其冻结。

• 冻结的作用

  冻结不会改变事务的可见性规则。冻结的唯一目的是防止事务 ID 回绕时因重复使用老的事务 ID 而导致可见性问题。被冻结的事务对所有事务都是可见的，因此不会对数据一致性产生影响。

事务 ID 回绕与冻结的关系

当事务 ID 达到最大值并回到 0 时，如果没有冻结老事务的机制，新的事务可能会与旧的事务 ID 发生冲突，从而导致数据可见性问题。为了避免这种情况，PostgreSQL 会通过冻结来确保非常老的事务 ID 在回绕后不会干扰新事务的可见性。

假设当前事务 ID 为 101，那么 PostgreSQL 会通过 VACUUM 操作，将非常老的事务（它们的 ID 比当前事务小很多）标记为冻结状态（TXID = 2）。这样，当事务 ID 再次回绕到 101 时，这些老事务已经被冻结，不会影响新的事务。

冻结不会改变事务之间的可见性关系。冻结只针对非常旧的事务，且这些事务已经对所有当前和未来的事务可见。冻结只是标记这些元组为永久可见，避免事务 ID 回绕时的混淆。

由于事务 ID 是有限的，当事务 ID 走到最大值时，它会“回卷”到初始值（如图中的 3）。这就是环形结构的关键点。为了避免新事务与旧事务产生冲突，PostgreSQL 会对旧事务进行处理，将其标记为“冻结”状态。冻结的事务对任何新事务都是可见的，但不再参与事务 ID 的竞争。

图中的第三部分展示了事务 101 被回收并变成了 2， 101被回收被未来事务使用。这个过程确保了 TXID 不会耗尽，并保证了数据的一致性。

TXID 之间的比较

事务的可见性与 TXID 的比较有密切关系：

• TXID > 当前事务的 TXID: 事务处于活跃状态，或尚未开始，因此对当前事务不可见。

• TXID < 当前事务的 TXID: 事务已提交或已回滚，对于当前事务可见。

  

  这个图展示了 PostgreSQL 中事务的可见性规则。它通过一个线性时间轴和一个环形结构来表明不同事务的状态，以及哪些事务对当前事务是可见的，哪些是不可见的。我们可以按照事务的执行顺序和可见性规则进行分析。

  一、事务的类型和状态

  图中的事务分为三类，分别是：

  1. 已完成事务（左边蓝色的部分）：

     • S (Start) 和 P (Past)：表示过去已经完成的事务，已经提交或回滚，因此对当前事务是可见的。
     • C：当前事务自己，此时可以看到自己已执行的操作。

  2. 正在进行的事务（右边黄色的部分）：

     • F1、F2、FD：表示未来的事务或正在执行的其他事务。这些事务还未完成，因此对当前事务是不可见的。

  二、事务的可见性

  1. 已完成事务可见

  • S 和 P 代表过去的事务，它们已经完成（提交或回滚），因此对于当前的事务（C），这些事务是可见的。
  • C 是当前事务，它可以看到自己执行的操作。

  2. 对自身可见

  • 当前事务 C：当前事务可以看到自己执行的操作。因此，在事务 C 中，自己对数据库的修改是可见的。

  3. 正在进行的事务不可见

  • F1、F2、FD：这些事务表示正在进行或者未来的事务。由于它们尚未提交，因此对当前事务 C 来说，不可见。这些事务的操作结果无法在当前事务中读取或影响当前事务的结果。

  三、环形结构中的事务

  右边的环形结构再次说明了事务的可见性规则：

  • P 和 C 代表已经完成的事务（或者当前事务），因此对当前事务 C 可见。

  • F1、FD 和 F2 是未来的或者正在进行的事务，由于它们还未完成（提交或回滚），因此对当前事务 C 是不可见的。

  • 已完成的事务：对当前事务 C 是可见的，包括过去已经提交的事务。

  • 对自身可见：当前事务 C 可以看到自己所做的修改。

  • 正在进行的事务：对当前事务 C 是不可见的，因为这些事务还没有提交或完成。

3. 事务快照（Transaction Snapshot）

事务快照 是事务在特定时间点所看到的其他事务的状态。它用于确定当前事务在何时能够看到其他事务的操作结果。事务快照的格式为 xmin:xmax:xip_list，其中：

• xmin 是可见的最小事务 ID。
• xmax 是可见的最大事务 ID。
• xip_list 列出了当前活跃事务的列表。

例如，假设一个事务 C 的快照为 [C:C:[F1,F]]，其中 F1 和 F 是其他事务的 TXID。对于事务 C 来说：

• 如果某个 TXID 小于 C 的 TXID，则该事务已终止（提交/回滚），因此可见。
• 如果某个 TXID 大于 C 的 TXID，则该事务仍在进行中，因此不可见。

4. 提交日志（Commit Log）

PostgreSQL 使用提交日志（Commit Log，简称 CLOG）来记录事务的状态。CLOG 是一个逻辑上的数组，由共享内存中的一系列 8KB 页面组成。每个事务的 TXID 对应数组中的一个位置，记录了该事务的状态（已提交、已回滚等）。

CLOG 数据会定期写入到 pg_xact 文件夹下，以确保事务信息的持久化和可追溯性。

事务总结

PostgreSQL 的事务机制提供了强大的并发处理能力和数据一致性保证。通过事务 ID 和事务快照，PostgreSQL 确保了事务的隔离性和可见性。同时，环形的 TXID 结构和提交日志保证了事务处理的高效和持久性。理解这些机制有助于我们更好地设计和优化数据库应用。

在多个事务并发执行时，事务ID（特别是在多版本并发控制机制下）主要用于解决数据的可见性问题。它帮助决定一个事务是否能够看到其他事务的提交结果。然而，事务ID本身并不能解决并发操作引发的数据冲突问题。当多个事务尝试同时对同一数据进行修改时，可能会发生数据冲突。为了解决这些冲突，数据库引入了锁机制，以确保数据的一致性和完整性。在下一个章节中，我们将详细介绍如何通过锁机制来处理事务之间的冲突，避免数据的不一致性。

PostgreSQL 锁机制

锁的引入是为了在并发环境下保证数据库的一致性和完整性。在并发事务中，为避免数据竞争和不一致问题，锁的机制是通过限制事务对共享资源的访问来实现的。

1. 数据库锁的本质：在并发操作中，多个事务可能同时想要读取或修改相同的数据，若没有任何约束，可能导致数据的读取不一致或修改冲突。锁就是对资源访问的控制手段，确保多个事务在执行时不会对数据产生冲突。

2. 锁的种类：根据操作的不同，锁可以分为读锁和写锁。为了保证更好的并发性能，PostgreSQL 进一步细化了锁的层次，允许在并发安全的前提下，尽量减少锁冲突。

3. 锁的冲突规则：不同锁之间的冲突规则决定了某种锁是否与另一事务的锁兼容。例如，读操作可以并发进行，因此多个共享锁可以被同时持有；而写操作需要排他性，因此写锁需要等待其他事务的读写锁释放。

4. 细粒度并发控制：为了避免完全串行化执行导致的性能瓶颈，锁被划分为不同的级别。这些锁级别允许在不同操作场景下使用适当的锁，既保证操作的安全性，又尽量减少对其他事务的影响。

锁的分类与设计原则

PostgreSQL 中的锁机制可以从以下几个维度进行分类，基于读写需求和表/行的操作粒度：

1. 共享锁 (Share Locks)：允许多个事务同时读取相同数据，但不允许写操作。
2. 排他锁 (Exclusive Locks)：确保只有一个事务可以对数据进行修改，其他任何读写操作都必须等待。
3. 行级别和表级别锁：行级锁允许更高的并发性，而表级锁则用于保护更大范围的操作（例如结构修改）。

锁的类型与冲突矩阵

为了更好地理解 PostgreSQL 锁的相互影响，我们可以整理出常见锁的分类，并总结其相互之间的冲突规则。

锁类型	允许并发的操作	阻止的操作
ACCESS SHARE	读取操作	阻止 ACCESS EXCLUSIVE 操作（如 DROP、TRUNCATE）
ROW SHARE	读取及行级锁定	阻止表结构更改操作（如 ALTER TABLE）
SHARE UPDATE EXCLUSIVE	维护操作（VACUUM）	阻止表结构更改操作和其他维护操作
ROW EXCLUSIVE	行级修改操作	阻止其他写操作，但允许并发读取
SHARE	并发读取	阻止行级别的写操作和表结构更改
EXCLUSIVE	表级修改操作	阻止所有其他事务的读写操作
ACCESS EXCLUSIVE	表结构修改	阻止所有其他事务的读写及表结构修改

在 PostgreSQL 中，锁机制用于保证数据库操作的并发一致性，防止数据竞争条件或不一致的情况。不同类型的锁（例如 SHARE、EXCLUSIVE 等）允许控制对某些资源的访问，以保持数据的完整性。下面我们从第一性原理的角度逐一解释这些锁的含义、原理以及应用场景。

1. SHARE 锁 (SHARE Lock)

含义

SHARE 锁允许多个事务同时读取同一行数据，但不允许修改或删除该行。换句话说，多个事务可以共享对资源的读访问权，但不能进行写操作。

原理

• 当一个事务获取了 SHARE 锁，其他事务也可以获取 SHARE 锁。
• 若有事务试图获取 EXCLUSIVE 锁（例如更新或删除数据），则必须等待所有现有的 SHARE 锁释放。
• 这种锁通常用于需要保护读操作不被写操作干扰的场景。

应用场景

适用于需要确保多个事务并发读取相同数据，且不希望数据在读取期间被修改的场景。例如：

• 某个报告或者统计查询需要读取一批数据，并且在读取过程中不允许这些数据被其他事务修改。

2. EXCLUSIVE 锁 (EXCLUSIVE Lock)

含义

EXCLUSIVE 锁用于确保只有一个事务可以访问（读或写）某个资源。它禁止其他事务同时获取 SHARE 锁和其他类型的排他锁。

原理

• 当一个事务持有 EXCLUSIVE 锁时，其他任何事务都无法获取该资源的 SHARE 或 EXCLUSIVE 锁。
• 这意味着持有 EXCLUSIVE 锁的事务可以对资源进行独占操作，确保操作的完整性。

应用场景

当需要对资源进行修改（如更新或删除）且不希望其他事务干扰时使用。例如：

• 一个事务需要更新某个行的数据，并确保在更新完成之前没有其他事务可以读取或修改这行数据。

3. ACCESS SHARE 锁 (ACCESS SHARE Lock)

含义

ACCESS SHARE 锁是最常见的锁，它允许多个事务同时读取数据。这种锁不会阻止其他事务读取或写入数据。

原理

• ACCESS SHARE 锁与 SHARE 锁类似，但它不阻止其他事务获取 EXCLUSIVE 锁。
• 这种锁是事务在执行 SELECT 查询时自动获取的锁。
• 它允许并发读取，但不会干扰写操作。

应用场景

ACCESS SHARE 锁通常用于只读查询，例如：

• 大量事务同时读取某些数据，而不需要担心数据一致性问题，因为读取不会阻止其他事务的写操作。

4. ACCESS EXCLUSIVE 锁 (ACCESS EXCLUSIVE Lock)

含义

ACCESS EXCLUSIVE 锁是最严格的锁类型，它会阻止其他事务访问相关的资源，除非该锁被释放。

原理

• 当一个事务持有 ACCESS EXCLUSIVE 锁时，其他事务不能获取任何与该资源有关的锁，包括 ACCESS SHARE 锁。
• 通常在执行 ALTER TABLE、DROP TABLE 或 TRUNCATE 等操作时自动获取。

应用场景

适用于需要完全独占资源的场景，例如：

• 修改表结构或删除表时，确保没有其他事务正在访问该表。

5. ROW SHARE 锁 (ROW SHARE Lock)

含义

ROW SHARE 锁允许多个事务同时获取该锁，且不阻止普通的 SELECT 查询，但防止其他事务给该表加上排他的锁（如 ACCESS EXCLUSIVE 锁）。

原理

• ROW SHARE 锁在执行 SELECT FOR UPDATE 或 SELECT FOR SHARE 时自动获取。
• 这种锁通常是对表级别的锁，防止其他事务对表进行结构上的变更（如 DROP 或 ALTER）。

应用场景

适用于需要对某些行进行更新或锁定以确保数据一致性的场景。例如：

• 在执行 SELECT FOR UPDATE 时，锁住某些行以防止其他事务修改这些行。

6. ROW EXCLUSIVE 锁 (ROW EXCLUSIVE Lock)

含义

ROW EXCLUSIVE 锁用于防止同一资源被多个事务同时修改。它允许其他事务读取数据，但不允许其他事务添加、修改或删除数据。

原理

• ROW EXCLUSIVE 锁通常用于 INSERT、UPDATE 或 DELETE 操作。
• 它是表级别的锁，允许并发读取，但不允许其他事务对表进行修改或添加排他锁。

应用场景

适用于需要插入或更新数据的场景，例如：

• 一个事务需要插入新数据到表中，并阻止其他事务同时插入、删除或修改该表的数据。

7. SHARE UPDATE EXCLUSIVE 锁 (SHARE UPDATE EXCLUSIVE Lock)

含义

SHARE UPDATE EXCLUSIVE 锁用于防止并发的 VACUUM 和 ANALYZE 操作，但允许大多数其他操作继续。

原理

• 在执行 VACUUM 或 ANALYZE 时获得此锁，以防止同时进行表的结构性修改。
• 它允许事务获取 ACCESS SHARE、ROW SHARE 和 SHARE 锁，但不允许获取表级别的排他锁。

应用场景

通常在需要维护表的统计数据或清理已删除数据的场景下使用。例如：

• 当执行 VACUUM 清理操作时，需要确保没有其他事务结构性修改表。

PostgreSQL 提供了多种锁类型，旨在平衡并发性能和数据一致性。每种锁的设计都基于以下第一性原理：

1. 并发控制：保证多个事务在并发执行时，数据的完整性和一致性。
2. 冲突避免：不同类型的锁定义了事务之间的冲突规则，确保读写操作在正确的条件下可以安全并发进行。
3. 性能优化：根据操作的不同（如读操作、写操作、表结构操作），使用不同的锁来最大化并发性能。

综合这些锁的设计，可以根据不同的应用场景选择适合的锁类型，既能保证数据安全，又能提高并发性能。

冲突矩阵

我们可以用一个冲突矩阵来表示各类锁之间的冲突关系：

锁类型	ACCESS SHARE	ROW SHARE	SHARE	ROW EXCLUSIVE	SHARE UPDATE EXCLUSIVE	EXCLUSIVE	ACCESS EXCLUSIVE	保护的资源
ACCESS SHARE	✓	✓	✓	✓	✓	✓	✗	表或视图，读取数据
ROW SHARE	✓	✓	✓	✓	✓	✗	✗	表中单行，通常用于SELECT FOR UPDATE
SHARE	✓	✓	✓	✗	✗	✗	✗	表，允许读取但不允许修改表
ROW EXCLUSIVE	✓	✓	✗	✓	✗	✗	✗	表中单行，通常用于写操作
SHARE UPDATE EXCLUSIVE	✓	✓	✗	✗	✗	✗	✗	表，用于防止其他事务获取行锁
EXCLUSIVE	✓	✗	✗	✗	✗	✗	✗	表，通常用于独占写操作，但允许快照读，与access shared兼容
ACCESS EXCLUSIVE	✗	✗	✗	✗	✗	✗	✗	表，防止任何其他会话访问该表。通常的 DDL（数据定义语言） 操作大多会使用 ACCESS EXCLUSIVE 锁，因为这些操作涉及对表结构的修改，要求完全独占对表的访问。

资源说明：

• 表或视图：主要用于查询数据的锁。
• 表中单行：锁定表中的某一行，通常用于更新或选择特定行。
• 表：锁定整个表，防止其他事务读取或写入。
• ✓ 表示锁之间可以共存（兼容）。
• ✗ 表示锁之间存在冲突，事务需要等待。

锁机制的规律总结

从 PostgreSQL 锁机制的设计中，我们可以总结出以下规律：

1. 读读共享，写写排他：多个事务可以共享读取（ACCESS SHARE 锁），但是一旦有写操作（ROW EXCLUSIVE 锁或更高级别），则需要排他锁，阻止其他写操作。
2. 行级操作与表级操作的分离：ROW EXCLUSIVE 锁允许行级别的修改，而表级别的锁（如 EXCLUSIVE）则用于表的整体修改或结构更改。行级锁的设计是为了允许更多的并发操作，尽量减少锁冲突。
3. 维护操作的专用锁：例如 SHARE UPDATE EXCLUSIVE 锁，允许某些维护操作（如 VACUUM 和 ANALYZE）与其他读取操作并发进行，但防止与表结构修改发生冲突。

进一步理解ROW SHARE与RULE EXCLUSIVE

ROW SHARE 和 ROW EXCLUSIVE 是表级锁。它们的作用是防止高冲突的表级操作（如 EXCLUSIVE 或 ACCESS EXCLUSIVE 锁所代表的操作），但允许并发的行级操作。这些锁允许多个事务在表上进行行级别的操作（如读取、更新），并且彼此之间不会产生冲突。

1. ROW SHARE 和 ROW EXCLUSIVE 是表级锁，但与行级操作有关

• 简单解释：ROW SHARE 和 ROW EXCLUSIVE 锁是针对表的锁，它们不会锁定整个表中的所有行，而是允许事务在表中操作某些行。

• 深入解释：这些锁的主要作用是确保事务可以对表中的特定行进行操作，同时防止其他事务在同一个表上执行破坏性的表级操作（如 ALTER TABLE 或 DROP TABLE）。但是，它们不会阻止其他事务对表中的不同行进行操作。

• 示例：你可以把它想象成在餐厅的桌子上做笔记。你在某个桌子上写字，但其他人也可以在同一个桌子上的不同位置做笔记。你们不会互相干扰（即行级操作不冲突）。但是，如果有人想直接搬走整个桌子（类似于 ACCESS EXCLUSIVE 锁），那就会阻止所有人继续使用这个桌子。

2. ROW SHARE 与 ROW EXCLUSIVE 之间的兼容性

• 简单解释：ROW SHARE 和 ROW EXCLUSIVE 锁是兼容的，因为它们允许多个事务对表中的不同行进行操作。两者之间不会因为行级操作而产生冲突。

• 深入解释：ROW SHARE 锁通常用于读取操作（如 SELECT ... FOR SHARE），而 ROW EXCLUSIVE 锁用于修改操作（如 UPDATE、INSERT、DELETE）。这两种锁都允许其他事务在表中执行不同的行级操作，因此它们可以共存。

• **示例：想象你和朋友在同一张桌子上做不同的事。你在桌子的左边阅读（ROW SHARE），而你的朋友在右边写字（ROW EXCLUSIVE）。你们互不干扰，因为你们在做不同的事情。

3. 它们与表级操作的冲突

• 简单解释：如果有事务试图对整个表进行操作（如 ALTER TABLE 或 TRUNCATE），那么这些操作需要获取更高级别的锁（如 EXCLUSIVE 或 ACCESS EXCLUSIVE 锁）。在这种情况下，ROW SHARE 和 ROW EXCLUSIVE 锁都会与这些锁冲突，导致事务被阻塞或等待。
• 深入解释：EXCLUSIVE 和 ACCESS EXCLUSIVE 锁用于全表操作，它们要求独占对整个表的访问权限，因此即使表上有事务只是针对几行进行操作（如 ROW SHARE 或 ROW EXCLUSIVE），这些锁也会彼此冲突。
• **示例：回到餐厅的比喻，如果有人想把整张桌子搬走（类似于 ACCESS EXCLUSIVE 锁），那么不管桌子上的每个人在做什么（读书或写字），所有人都必须停下来等桌子被搬走。

进一步理解EXCLIUSIVE与ACCESS EXCLUSIVE

1. EXCLUSIVE 和 ACCESS EXCLUSIVE 锁的定义和用途

EXCLUSIVE 锁

• 用途：EXCLUSIVE 锁用于防止其他事务对表中的数据进行修改，但允许读取操作。它通常通过以下语句显式地加锁：

  LOCK TABLE table_name IN EXCLUSIVE MODE;
  

• 影响：持有 EXCLUSIVE 锁的事务可以对表中的数据进行修改（如 INSERT、UPDATE、DELETE），但其他事务只能对表进行读取（持有 ACCESS SHARE 锁）。其他事务不能对表进行修改或获取更高级别的锁（如 ROW EXCLUSIVE、ACCESS EXCLUSIVE 锁）。

• 允许的操作：EXCLUSIVE 锁允许其他事务读取表中的数据（即允许 SELECT），但不允许其他事务对表中的数据进行任何形式的修改（包括 INSERT、UPDATE、DELETE 等）。

ACCESS EXCLUSIVE 锁

• 用途：ACCESS EXCLUSIVE 锁是 PostgreSQL 中最严格的表级锁，主要用于 DDL 操作（数据库定义语言操作），如 ALTER TABLE、DROP TABLE、TRUNCATE 等。这种锁会阻止其他事务对表进行任何操作，不论是读取（SELECT）还是写入（INSERT、UPDATE、DELETE）。

• 影响：持有 ACCESS EXCLUSIVE 锁的事务完全独占对表的访问权限，其他事务在此期间不能对表进行任何操作，包括读取和修改。通常，ACCESS EXCLUSIVE 锁是隐式获取的，主要用于执行 DDL 操作。

• 允许的操作：在持有 ACCESS EXCLUSIVE 锁期间，其他事务不能对表进行任何操作。这种锁在以下场景中使用：

  • ALTER TABLE
  • DROP TABLE
  • TRUNCATE
  • REINDEX
  • VACUUM FULL

2. 锁之间的冲突

• EXCLUSIVE 锁与其他锁的冲突：

  • EXCLUSIVE 锁与任何试图对表进行 写操作 的锁（如 ROW EXCLUSIVE、EXCLUSIVE、ACCESS EXCLUSIVE）冲突。
  • 但是，EXCLUSIVE 锁允许其他事务持有 ACCESS SHARE 锁（即读取锁）。这意味着其他事务可以在表上执行 SELECT 查询，但不能对表进行修改。

• ACCESS EXCLUSIVE 锁与其他锁的冲突：

  • ACCESS EXCLUSIVE 锁与所有其他锁冲突。它不仅阻止其他事务对表进行任何形式的修改，还阻止其他事务读取表的数据。
  • 换句话说，ACCESS EXCLUSIVE 锁是完全排他性的，在持有此锁时，其他事务不能执行任何与该表相关的操作。

3. EXCLUSIVE 和 ACCESS EXCLUSIVE 锁的区别

• 锁的范围：

  • EXCLUSIVE 锁的主要目的是防止其他事务对表中的数据进行修改，但仍然允许读取操作。
  • ACCESS EXCLUSIVE 锁是最严格的锁，它不仅阻止修改，还阻止读取，确保事务对表的完全独占访问。

• 使用场景：

  • EXCLUSIVE 锁通常用于需要对表进行修改但不希望其他事务修改数据的情况，比如在批量更新时，事务可能会显式地锁定表。
  • ACCESS EXCLUSIVE 锁主要用于DDL操作，例如修改表结构时，必须确保没有其他事务在访问该表。

图表表示

为了更清晰地表示锁的层次与冲突关系，我们可以用图表来展示：

在这张图中：

• 每个锁类型按严格程度从上到下排列。
• 箭头表示锁的层次关系（即，越往下，锁越严格）。
• 图中最上层的 ACCESS SHARE 锁允许并发读操作，而越往下，锁的排他性越强，直到 ACCESS EXCLUSIVE 锁，几乎阻止任何其他操作。

总结

事务主要解决的是数据的可见性问题，即事务之间如何相互“看到”数据的变化。

锁主要解决的是并发性问题，即多个事务在并发操作相同数据时，如何确保数据的一致性和防止竞争条件。

在冲突时，系统根据可见性规则和锁机制来决定事务的处理方式，比如是否等待、失败回滚，还是直接成功。

1. 事务和可见性

   事务通过实现不同的隔离级别来控制数据的可见性。数据库会根据事务的隔离级别决定一个事务在什么时候可以看到其他事务的修改，或者其他事务的修改对当前事务不可见。常见的隔离级别有：

   • 读未提交（Read Uncommitted）：事务可以看到其他未提交事务的修改，会导致“脏读”。

   • 读已提交（Read Committed）：事务只能看到其他事务已提交的修改。

   • 可重复读（Repeatable Read）：事务在整个过程中的读操作，看到的数据都是一致的，即使其他事务提交了修改，当前事务读到的数据也保持不变。

   • 可序列化（Serializable）：最严格的隔离级别，事务执行的结果必须与按某个顺序串行执行的结果相同。

   每个隔离级别都通过不同的可见性规则来控制事务对于数据修改的访问。这就是事务解决的可见性问题。

2. 锁和并发性

   锁机制用于确保并发事务不会破坏数据的一致性。锁的种类有很多，主要包括：

   • 共享锁（Share Lock）：允许读取但不允许写入。同样的数据可以被多个事务读取，但不能有事务同时修改它。

   • 排他锁（Exclusive Lock）：允许数据的修改，并阻止其他事务读取或修改同一数据。

   • 行级锁、表级锁：控制锁的粒度，可以对单行或整个表加锁。

   锁用于解决并发性问题，确保多个事务同时操作相同的数据时，数据保持一致，避免如“脏写”、“丢失更新”等并发问题。

3. 冲突时的处理

   当多个事务对同一个数据进行并发操作时，会产生冲突。冲突可以分为可见性冲突和并发冲突，这时系统会根据可见性规则和锁机制，决定如何处理冲突。3.1 判断是否等待、失败或成功

   在冲突时，系统会根据以下情况来决定事务的处理方式：

   • 是否能看到对方的修改（可见性）：根据事务的隔离级别，决定当前事务是否可以看到其他事务的修改。如果隔离级别允许看到修改，那么可以继续操作；否则，可能会阻塞或失败。

     • 例如，在 READ COMMITTED 隔离级别下，事务只能看到已提交的数据。如果事务 A 修改了某行数据但未提交，事务 B 在读取该行时会被阻塞，直到事务 A 提交或回滚。

     • 在 REPEATABLE READ 隔离级别下，事务 B 即使在事务 A 提交后，也只会看到事务 B 开始时的快照数据（事务 A 的修改对事务 B 不可见）。因此，事务 B 不会被阻塞，但可能会导致冲突（如写冲突），并在事务提交时检测到。

   • 锁的冲突：如果两个事务试图获取相互冲突的锁，系统会决定是否让一个事务等待或回滚。

     • 如果一个事务持有共享锁（用于读取），另一个事务想要获取排他锁（用于修改），后者会被阻塞，直到前者释放共享锁。
       • 如果两个事务都试图获取排他锁（例如同时修改同一行），系统会让后提交的事务等待，或者直接回滚其中一个事务。

   3.2 基于可见性判断事务是否成功或失败

   在冲突发生时，系统会通过事务的可见性规则来决定事务是否应该失败或者成功。这种情况下，事务的可见性和锁机制是紧密结合的。

   • 快照隔离（Snapshot Isolation）：在快照隔离级别下（如 REPEATABLE READ），每个事务在开始时会获取一个数据库的快照。在事务的整个生命周期中，读操作只会看到快照中的数据，而不会看到其他事务的修改。这种隔离级别下，事务之间的冲突通常不会立即表现为锁冲突，而是通过可见性判断是否有读写冲突。如果事务之间存在依赖关系，可能会导致事务在提交时失败。

     • 例如，事务 A 读取了一行数据，事务 B 修改了这行数据并提交。当事务 A 尝试提交时，系统会检测到事务 A 读取的数据已经被事务 B 修改，从而导致冲突，事务 A 可能会被回滚。

   • 串行化隔离级别（Serializable Isolation）：在 SSI（Serializable Snapshot Isolation）机制下，系统会动态跟踪事务之间的依赖关系。如果系统检测到某些事务之间存在潜在的冲突（如读-写冲突或写-写冲突），则会根据事务的依赖关系决定是否中止其中一个事务。

     • 例如，事务 A 读取了某一行，事务 B 修改了同一行并提交。系统会跟踪事务 A 和事务 B 的依赖关系。如果事务 A 在提交时，系统发现事务 B 的修改影响了事务 A 的读取结果，则可能会中止事务 A。

4. 等待、失败或成功的决策流程

   当事务之间发生冲突时，具体的决策流程可以简化为以下几步：

   事务是否看到其他事务的修改：

   • 如果隔离级别允许看到修改，并且没有冲突，事务继续执行。
   • 如果隔离级别不允许看到修改，系统会使用锁机制阻止事务访问冲突的数据，直到锁释放。

   是否存在锁冲突：

   • 如果两个事务请求冲突的锁（例如共享锁 vs 排他锁），系统会让一个事务等待，直到另一个事务完成。
   • 如果无法等待（如死锁检测时发现循环依赖），系统会回滚其中一个事务。

   提交时的冲突检测：

   • 在 REPEATABLE READ 或 SERIALIZABLE 隔离级别下，系统会在提交时再次检查事务之间的冲突。如果发现事务读取了其他事务已修改的数据，则该事务会被中止以确保一致性（如 SSI 中的依赖图检测）。

   • 事务的可见性：事务的可见性通过隔离级别控制，决定一个事务在多大程度上能看到其他事务的修改。不同的隔离级别提供不同的可见性规则，影响事务的行为。

   • 锁的并发控制：锁机制确保并发事务不会破坏数据的一致性，通过锁定资源来防止事务在同一时间修改相同的数据。锁的冲突会导致事务等待或失败。

   • 冲突时的决策：

     • 根据可见性判断：事务中途是否看到其他事务的修改，决定是否允许继续执行或触发冲突检测。
       • 锁冲突：如果锁冲突，系统会决定是否等待、失败或成功。
       • 冲突检测：在提交时，系统会根据事务之间的依赖关系判断是否存在不一致的情况，并决定是否中止事务。

通过事务的可见性规则和锁机制，数据库系统能够在高并发环境中实现数据一致性和事务隔离。冲突时，系统会根据可见性规则和锁的冲突情况来决定事务的最终命运：等待、失败回滚，还是继续成功执行。锁机制的设计是为了在保证并发一致性的前提下，尽可能提升数据库的吞吐量。锁的细化允许在不同的应用场景中使用最适合的锁级别，既保证操作安全，又尽量减少对其他事务的影响。