索引外键列

Question

在所有外键列上放置索引是否是一条经验法则？看起来他们经常被用在表连接中，并且会从索引中获益。

如果FK列只有2或3个可能值会怎么样？例如，如果它正在引用状态表。将索引放在FK字段上仍然是可取的吗？

编辑 我想重新做这个问题。 [是不是最好把索引列上几乎没有可能的值（2或3）？] 编辑完

Answer 1

（两个问题走到一起的位置：机器效率和DBA的效率。）

作为一个经验法则，查询性能优势从指标上使用JOIN子句列在WHERE子句。当然，插入，更新和删除性能也会受到相同索引的影响。 （因为索引必须与表一起更新）

如果某列的值很少，并且有一个令人信服的理由来避免在表中存储实际值，那么我更喜欢使用人类可读的代码作为外键引用的目标。例如，ISO 5218规定了代表人类性别的这些代码。

Sex_id Sex 
-- 
0  Not known 
1  Male 
2  Female 
9  Not applicable 

我不希望人们记住意味着不适用。如果这是我的全部，那么我每次需要输出供人阅读时都必须加入这张表。

但我可以添加一列到该表中，声明它是唯一的，并将其用作外键引用的目标。大部分时间我都不需要加入这张桌子。哎呀，我可能从来没有必须加入它。避免加入与机器效率有关。

sex_id sex_code sex 
-- 
0  Un   Not known 
1  M   Male 
2  F   Female 
9  NA   Not applicable 

所有这三列应声明为唯一。而在大多数平台上，这意味着这三列中的每一列都会得到一个索引。即使选择性会很低，我也会对引用sex_code的列进行索引。

为什么？我有更好的事情要做，比重新评估是否增加一个索引现在，因为这个版本的优化器足够聪明地利用它。这与DBA的效率有关。

Answer 2

不，它不应该。索引只能在使用时使用。只有当表格尺寸足够大时，索引才有用，例如至少有三个块。对于短行，这可以很容易地为数百行。

Answer 3

我会强烈反对Eelke - 大多数SQL Server大师将推荐在外键列上放置一个非聚集索引，我同意。

有关这些指数的理由和最佳论证的最佳总结，请参阅Kimberly Tripp的优秀博客文章When did SQL Server stop putting indexes on foreign keys? - 答案是：从不 - 它从来没有这样做（这是许多持续的城市神话之一 - 但它仍然是一个神话）。

她的核心信息是：

在那里索引 外键列什么好处？ 是在维护上 关系

• 更好的性能，删除主键/唯一键的。当 您删除一个关键行时，SQL Server必须 检查是否有任何行 引用了要删除的行。
  o如果外键关系没有处理 定义（在更新/删除），然后引用 行不能被删除，因为它会 离开引用行“孤立”。 要查找的行有效的索引 上外键列帮助！
  o如果外键关系与CASCADE定义 （上更新/删除），则当 参考行要修改所有的 引用行的必须被修改为 以及（或者更新以反映 新值或上级联删除）。到 找到要修改的行， 外键列 有帮助！

• 更好的连接性能 - 对于许多的上述原因，SQL服务器 可以更有效地找到行 加入时表的连接 主/外键关系来。 但是，这并不总是“最好的” 连接的索引选择，但它是一个良好的开始 。