在SQL Server 2008中，关系能够提高查询速度吗？

Question

例如，如果我有一个BlogPosts表和一个PostCategory表，其中BlogPosts表有一个FK字段PostCategoryId。关系是否会使查询更快，还是更多地考虑数据质量？

当涉及联接表时呢？从BlogPosts表中取出PostCategoryId字段，并在它们之间添加一个名为PostsInCategories的表，该表只有2个FK字段：BlogPostId和PostCategoryId，组合形成PK。

在那里，关系能改善查询吗？

- Chaddeus

---

创建并使用带有外键的附加表会减慢选择和修改的速度。但这种方法可以改善设计。 - zerkms

我的理解是，这实际上会使它变慢，但会帮助您维护引用完整性。如果您追求绝对优化，关系通常会减慢速度。 - Stefan H

数据库关系 - Stefan H

Answer 1

外键关系主要是为了强制数据完整性，例如确保没有任何“巫毒神婴”行，也就是没有父行的子行；而外键关系本身并不会提高性能，因为SQL Server不会自动为外键创建索引。

出于多种原因（如实施引用完整性和提高JOIN性能——请参见Kimberly Tripp有关此主题的博客文章），强烈建议为表中的所有外键字段添加索引——添加这些索引将加速使用这些FK关系的查询。

- marc_s

---

谢谢Marc_s。我本来就是这么想的，只是想确认一下。 - Chaddeus

当然，我阅读了FKs部分，但它并没有涉及到相反的观点，即省略索引可能是一个好主意，即缺乏平衡。 - onedaywhen

我从未听说过在外键列上创建索引是个坏主意的任何理由 - 我能帮忙 :) 巧合的是，我今天早些时候正在查看这篇文章。背景：Access（又名Jet）过去总是在FK的两端添加索引，但后来他们意识到这并不总是一个好主意，因此引入了“快速外键”功能。 - onedaywhen

他们都使用B树，但我们不要争论这个。相反，我给你留下两个想法：你能想象一个更新远远超过查询的环境，并且维护高度选择性索引的成本并不划算吗？还有，关于那些我读过的关于不创建高度选择性索引的文章：为什么他们没有提到FK作为规则的例外呢？ - onedaywhen

@ElRonnoco：你有没有意识到这是我和marc_c之间的来回对话，但后者随后删除了他们的评论？我留下了我的评论，因为它们仍然有效，即像“将索引添加到所有外键字段”这样的概括性建议仅仅是一个经验法则，并且存在特殊情况，例如在高活动环境中具有高选择性索引。 - onedaywhen