当在引用的表上存在索引时启用外键约束

在缺省情况下，当它们的模式更改为 ENABLED 时，数据库服务器自动地验证引用的约束。当 SET CONSTRAINTS 语句启用外键约束时，您可能节省时间，如果该引用的表在对应于外键约束的键的列上（或列的集合上）已有唯一索引或主键约束的话。

关于如何验证启用的外键约束，数据库服务器作出基于成本的决策。在许多上下文中，索引键算法可能更快，因为它通过仅扫描索引值，而不是索引表中所有的行来验证该约束。

数据库服务器可考虑使用索引键算法来验证它启用的外键约束，但当 SET CONSTRAINTS ENABLED 语句重置该约束模式时，仅当满足所有下列条件时才行：

SET CONSTRAINTS 语句仅正在启用一个外键约束。
如果是这种情况，则数据库服务器仅需要检查在其上正在启用外键约束的列上的个别值。同时验证两个外键约束可能会需要在同一扫描上使用两个索引，这是不支持的。
同一语句没有启用 CHECK 约束。
如果 SET CONSTRAINTS 语句正在启用多个约束，则验证 CHECK 约束会要求检查每行，而不是个别的值。在那种情况下，不可为了验证外键约束而使用索引键算法。
外键列不包括用户定义的数据类型（UDT）或内建的 opaque 数据类型。
要使得快速的索引键算法尽可能高效，它消除与用户定义的或内建的 opaque 数据类型相关联的所有执行例程的低效率，诸如 BOOLEAN 和 LVARCHAR 内建 opaque 类型。
外键约束的新模式不是 DISABLED。
如果它是启用的，则不需要约束检查算法，因为不会发生对引用的完整性违反的检查。
该表不与活动的违反表相关联。
在检查的时刻，违反表要求必须将不满足新约束的每行插入到违反表内。对每行进行违反扫描会防止数据库服务器使用跳过重复的行的更快的索引键算法。

除了在一个或多个违反行的情况之外，当不满足这些要求时，SET CONSTRAINTS 语句可启用并验证外键约束，但数据库服务器不会考虑使用索引键算法来验证外键约束。扫描整个表导致的附加验证成本通常与表的大小是成比例的。对于非常大的表，这些成本可非常可观。

当您启用自引用外键约束时，其 REFERENCING 子句指定在其上定义约束的同一表，数据库服务器可考虑索引键算法来验证引用的完整性，如果满足以上罗列的所有条件的话。