PostgreSQL 教程

Appearance

64.5. 索引唯一性检查# ​

PostgreSQL使用唯一索引来强制执行 SQL 唯一性约束，这些索引不允许具有相同键的多个条目。支持此功能的访问方法将amcanunique设置为 true。（目前，只有 b-tree 支持它。）在强制唯一性时，不会考虑INCLUDE子句中列出的列。

由于 MVCC，始终需要允许在索引中物理存在重复条目：这些条目可能引用单个逻辑行的连续版本。我们实际要强制执行的行为是，没有 MVCC 快照可以包含两个具有相等索引键的行。当将新行插入唯一索引时，这会细分为必须检查的以下情况

  • 如果当前事务已删除冲突的有效行，则没关系。（特别是，由于 UPDATE 在插入新版本之前始终删除旧行版本，因此这将允许在不更改键的情况下对行进行 UPDATE。）

  • 如果尚未提交的事务已插入冲突行，则准插入者必须等待以查看该事务是否提交。如果回滚，则没有冲突。如果提交而不再次删除冲突行，则存在唯一性冲突。（实际上，我们只需等到另一个事务结束，然后重新执行可见性检查即可。）

  • 类似地，如果尚未提交的事务已删除冲突的有效行，则准插入者必须等待该事务提交或中止，然后重复测试。

此外，在根据上述规则报告唯一性冲突之前，访问方法必须重新检查正在插入行的活动状态。如果已提交死，则不应报告违规。（在插入当前事务刚刚创建的行这种普通情况下，不会发生这种情况。但是，在CREATE UNIQUE INDEX CONCURRENTLY期间可能会发生。）

我们要求索引访问方法自行应用这些测试，这意味着它必须进入堆中以检查根据索引内容显示具有重复键的任何行的提交状态。毫无疑问，这是丑陋且不可模块化的，但它节省了重复的工作：如果我们进行单独的探测，则在查找插入新行索引条目的位置时，冲突行的索引查找本质上会重复。更重要的是，除非冲突检查是插入新索引条目的一个组成部分，否则没有明显的方法可以避免竞争条件。

如果唯一约束是可以延迟的，则会有额外的复杂性：我们需要能够为新行插入索引条目，但将任何唯一性冲突错误延迟到语句结束甚至更晚。为了避免对索引进行不必要的重复搜索，索引访问方法应在初始插入期间执行初步唯一性检查。如果这表明绝对没有冲突的活动元组，我们就完成了。否则，我们安排在强制约束时进行重新检查。如果在重新检查时，插入的元组和具有相同键的其他元组都处于活动状态，则必须报告错误。（请注意，出于此目的，“活动”实际上意味着“索引条目 HOT 链中的任何元组都是活动状态”。）为了实现这一点，aminsert函数传递了一个checkUnique参数，该参数具有以下值之一

  • UNIQUE_CHECK_NO 表示不应执行唯一性检查（这不是唯一索引）。

  • UNIQUE_CHECK_YES 表示这是一个不可延迟的唯一索引，且必须立即执行唯一性检查，如上所述。

  • UNIQUE_CHECK_PARTIAL 表示唯一约束是可延迟的。PostgreSQL 将使用此模式插入每一行的索引条目。访问方法必须允许重复条目进入索引，并通过从 aminsert 返回 false 报告任何潜在重复项。对于返回 false 的每一行，将安排延迟重新检查。

    访问方法必须识别可能违反唯一约束的任何行，但报告假阳性并非错误。这允许在不等待其他事务完成的情况下执行检查；此处报告的冲突不被视为错误，并将稍后重新检查，届时它们可能不再是冲突。

  • UNIQUE_CHECK_EXISTING 表示这是对报告为潜在唯一性违规的行进行的延迟重新检查。尽管这是通过调用 aminsert 实现的，但访问方法在这种情况下不 插入新索引条目。索引条目已经存在。相反，访问方法必须检查是否存在另一个活动索引条目。如果存在，并且目标行仍然处于活动状态，则报告错误。

    建议在 UNIQUE_CHECK_EXISTING 调用中，访问方法进一步验证目标行实际上在索引中确实具有现有条目，如果没有，则报告错误。这是一个好主意，因为传递给 aminsert 的索引元组值将被重新计算。如果索引定义涉及实际上并非不可变的函数，我们可能会检查索引的错误区域。检查目标行是否在重新检查中找到，可验证我们扫描的元组值与原始插入中使用的值相同。