FK 上的联接是否比没有 FK 的联接更快？

Question

假设我有两个表，a 和 b：

a {
 pk as int
 fk as int
 ...
}

b {
 pk as int
 ...
}

我想在查询中加入 a 和 b，如下所示：

FROM a
JOIN b on a.fk = b.pk

以下哪种情况会更快？

1. a.fk 设置为 b.pk 上的外键 - b.pk 已索引
2. a.fk 设置为 b.pk 上的外键 - b.pk 未建立索引，
3. 表之间没有关系 - b.pk< /code> 已索引，
4. 表之间没有关系 - b.pk 未编入索引

额外问题 - 每种情况会快/慢多少？

如果您可以用参考文献来支持您的答案，那就太好了。谢谢你！

Answer 1

最佳实践

1. 外键是一种关系完整性工具，而不是性能工具。您应该始终在 FK 列上创建索引以减少查找。 SQL Server 不会自动执行此操作。
2. 如此处所述 外键提高性能

从逻辑上讲，这给出了以下排名性能方面，

1. a.fk 设置为 b.pk 上的外键 - b.pk 已索引，
2. 两者之间没有关系桌子- b.pk 已建立索引
3. a.fk 设置为 b.pk 上的外键 - b.pk 未
4. 在那里 建立索引表之间没有关系 - b.pk 未建立索引

Answer 2

索引版本和非索引版本之间的性能差异最大，但是更快还是更慢将取决于它是选择还是插入。使用索引和外键约束会减慢插入速度，但会加快选择速度（索引）或使数据更可靠（FK）。由于通常大多数插入不会明显减慢（除非您正在进行大量插入），因此拥有 FK 和索引通常符合您的最佳利益。

Answer 3

我会同上利文的回答。只是为了回答您通过创建索引获得多少性能提升的额外问题，答案是“这取决于”。

如果一个或两个表都很小，并且它们是查询中仅有的两个表，则性能增益可能会小到零。当记录数量较少时，有时读取所有记录比使用索引更快。数据库引擎应该足够智能来解决这个问题——这就是“查询优化的全部内容”。

同样，如果涉及其他表和其他选择标准，数据库引擎可能决定不使用此索引，并且查找记录的其他方式更快。

在另一个极端，如果您有两个非常大的表，则在用于连接它们的字段上创建索引可以将运行时间缩短 99% 或更多。

这就是为什么学习阅读数据库引擎上的解释计划是一个好主意。如果查询需要很长时间，请运行解释计划并查看它在做什么。通常，创建一个好的索引可以显着改善查询。