Joe*_*ish 27 index foreign-key sql-server sql-server-2016
我正在尝试了解有关 SQL Server 2016 中引入的“外键引用检查”查询计划运算符的更多信息。关于它的信息并不多。微软在这里宣布了它,我在这里发表了关于它的博客。通过从具有 254 个或更多传入外键引用的父表中删除一行,可以看到新的运算符:dbfiddle link。
操作员详细信息中显示了三种不同的计数:
在这种情况下什么是部分匹配索引?我无法使以下任何一项工作:
INCLUDE索引列Dan Guzman指出,即使索引键与外键列的顺序不同,多列外键也可以匹配索引。他的代码在这里,以防有人能够使用它作为起点来找出更多关于部分匹配索引的信息。
Sea*_*ser 13
我与比我更聪明的人交谈过,我们很快就会记录下来™。
在此期间的实际定义是:
PartialMatchingIndexCount 反映了可以使用索引查找检查的引用数,但索引键并未涵盖所有被检查的列。例如,对应的 ForeignKeyReferenceCheck 元素同时包含 Seek Predicates 和 Predicate 元素。
此外:
如果此数字大于 0,则存在潜在的性能问题,以防部分匹配导致大量行。
经过更多谷歌搜索后,我设法找到了一篇提到“部分匹配索引”和外键的帖子
Carlos Klapp 的代码博客中 2013 年 3 月 1 日发表的博客文章Foreign Keys without Indexes名为“存储过程”,Util_FKsWithoutIndexes该过程会查找没有正确的 FK 关系索引的外键。(看起来这个博主是从SQL Server Central 中摘取的The Ultimate Index-Less Foreign-Key Finder(2009 年 10 月 15 日))博客内容如下:
搜索没有完全匹配索引的外键约束。
通过 MatchCounts 和列比较输出最佳部分匹配索引
为每个没有匹配索引或部分匹配索引的外键生成一个 CREATE INDEX 模板。
根据需要自定义(添加包含,如果您希望它聚集,或者它应该是主键的一部分,或者如果您想与另一个索引合并)
由于用于检查引用完整性的表扫描以及外键列位于 WHERE 或 JOIN 谓词中的引用表上的 SELECTS,缺少完全匹配索引的 FK 可能会严重损害引用表上的 DELETES 性能(这会影响你是否存在约束)。这仅检查索引的前 N 列,其中 N 是外键约束中的列数。
除此之外,不会验证索引列顺序(在 3 列索引的第 2 列中有 1 个匹配列的两列 FK 将作为部分匹配输出)
如果您的数据库没有外键约束,那么这个工具对您来说毫无价值。
许多数据库都有部分外键约束覆盖。这只适用于声明约束的相关表。
如果我理解正确的话,如果 FK 关系没有与某些所需索引中的每一列相匹配的索引,则可能有一些索引具有某些列。例如,如果 FK 关系具有三列 ( a, b, c) 但没有包含这三列的索引,则可能存在具有 ( a, b) 或 ( a, c) 或 ( b, c) 的索引,并且可能有助于查询,但不会需要对缺少列的行进行一些索引扫描。
如果根本不存在可以支持FK约束的索引,则“部分匹配索引计数”将为零( 0),或者至少不会增加该计数。
| 归档时间: |
|
| 查看次数: |
1725 次 |
| 最近记录: |