在SQL Server中使用外键有严重的性能下降吗？

我正在尽我所能说服我的老板让我们在我们的数据库中使用外键 - 迄今没有运气。在SQL Server中使用外键有严重的性能下降吗？

他声称这需要大量的性能，并表示我们现在只需要清理无效的参考资料。

很明显，这在实际中并不奏效，数据库中充斥着无效的引用。

有谁知道比较，基准或类似的证明没有显着的性能影响使用外键？（我希望能说服他）

2010-02-23 Steffen

只是整个故事的更新：现在我们被允许使用外键，如果它们可能被禁用，如果它们导致性能损失的概念。所以，非常感谢大家的好评:-) – Steffen 2010-02-25 06:54:57

由于必须检查FK，因此插入，更新和删除的性能很小。对于一个单独的记录来说，这通常会非常轻微以至于不明显，除非你开始有一个与桌子相关的可笑数量的FK（显然，检查100个其他桌子比2要花费更长的时间）。由于没有完整性的数据库是不可靠的，因此毫无用处，这是件好事。你不应该为了速度而诚实交易。这种性能影响通常被更好的优化执行计划的能力所抵消。

我们有一个中等大小的数据库，其中包含大约900万条记录和FK，并且很少注意到性能问题（除非一个设计错误的表有100多个外键，但删除记录有点慢从这一切都必须检查）。几乎每个dba，我知道谁处理大型TB级数据库，并且真正需要在大型数据集上获得高性能，因为完整性是任何数据库的关键，所以坚持外键约束。如果拥有太字节大小的数据库的人能够承受非常小的性能影响，那么你也可以。

FK不会自动编入索引，如果它们未编入索引，则会导致性能问题。

说实话，我会拿你的数据库的副本，添加适当索引的FKs，并显示插入，删除，更新和从这些表中选择的时间差，与没有FK的数据库中的相同。表明你不会造成性能下降。然后显示显示孤立记录的查询结果，这些记录不再具有含义，因为它们相关的PK不再存在。对于包含财务信息的表格显示这一点特别有效（“我们有2700个订单，我们无法与客户联系”将使管理层坐起来并留意）。

来源

2010-02-23 22:46:31 HLGEM

非常有用的信息。我目前正在将外键添加到数据库的副本中，但这需要一些时间，因为我必须先删除像2000万到3000万无效行。这仅仅证明首先缺少密钥的问题有多大。 – Steffen 2010-02-24 10:07:33

“你不应该为了速度交易完整性” - 但这是大多数NoSql数据库所做的事情......在某些情况下，这可能是值得的折衷，但在进行此调用之前，应该认真衡量实际效果。 – noocyte 2017-11-22 07:19:10

@noocyte，这就是为什么NoSql数据库通常不适用于任何严肃的商业应用程序，尤其是在金融和医疗保健等受监管行业。 – HLGEM 2017-11-22 16:07:31

从Microsoft Patterns and Practices: Chapter 14 Improving SQL Server Performance：

当主键和外键定义为数据库架构限制，服务器可以使用该信息，创造最优执行计划。

来源

2010-02-23 10:47:31

当然，它可以使用这些索引来优化......但这并不意味着对性能没有负面影响。我认为涉及太多的因素使这个问题睡在这个参考文献中。 – 2010-02-23 10:56:52

@罗兰：我明白你的意思了，我同意你的意见。但是我的意图是解决“我尽力说服我的老板”这个问题的一部分。 – 2010-02-23 10:58:16

@Roland：另外，性能受到的影响非常罕见。正如你在答案中所说的那样，在不知道应用程序的情况下很难声称，但实际上，外键的好处很少用于性能交易。相关SO帖子：http：// stackoverflow。com/questions/1744878/can-foreign-keys-hurt-query-performance/ – 2010-02-23 11:16:08

可以关注性能，但是让偏执决定不是。

你可以很容易地编写基准代码来自己展示结果，但首先你需要找出你的老板关心的是什么样的表现，并且准确地说明这些指标。就无效引用ar而言，如果你不允许你的外键有空值，你将不会得到无效的引用。如果您尝试分配一个不存在的无效外键，数据库将会被感知。如果你需要“空值”，分配一个键为“UNDEFINED”或类似的东西，并将其设为默认键。

最后，向你的老板解释数据库正常化问题，因为我认为你很快就会发现这个问题比以往的外键性能会更为棘手。

来源

2010-02-23 10:50:28 BenB

我很确定这不是他担心的任何确切的表现指标，因为他只是表示“它伤害了表现”，而这就是它。显然这并不容易证明是错误的:-( – Steffen 2010-02-23 11:48:03

如果有人需要“空”，他可以有空列，它不会在FKs上产生问题，我发现添加“自定义”“空行”在主表中为了不在外表中添加一个可为空的列比根本不使用FK更差 – 2014-10-09 21:48:17

如果你没有FK，那么不允许FK列中的空值不会阻止你进入无效的，如果原始PK记录被删除或改变，记录不会被孤立 – HLGEM 2017-07-03 13:50:55

有谁知道比较，基准或类似的证明没有显着的性能影响使用外键？（我希望能说服他）

我认为你会以错误的方式去做。基准从未说服任何人。

你应该怎么做，首先会发现不使用外键约束导致的问题。尝试量化“清理无效引用”需要花费多少工作量。另外，请尝试并衡量由于这些错误而导致业务流程出现多少错误。如果你可以附加一美元金额 - 甚至更好。

现在要进行基准测试 - 您应该尝试深入了解您的工作负载，确定哪种类型的操作最经常进行。然后建立一个测试环境，并用外键重放这些操作。然后比较。

就我个人而言，如果没有关于数据库上运行的应用程序的知识，我不会立即声明外键不会降低性能。特别是如果您将级联删除和/或更新与复合自然主键结合使用，那么我个人会担心性能问题，特别是由于级联操作的副作用导致的超时或死锁事务。

但是没有人能告诉你 - 你必须测试自己，包括你的数据，工作量，并发用户数量，硬件和应用程序。

来源

2010-02-23 10:51:34

关于应用程序的好处，但表格非常简单 - 所有主键都是标识整数，我们有没有级联删除/更新所以基本上它是如此简单：-D – Steffen 2010-02-23 11:40:42

Steffen，这是有用的信息。我可能没有任何保留，除非处理大量的写入负载。 – 2010-02-23 11:52:04

我相信我们的阅读方式比写作更多，所以这也不是什么大问题。感谢您的评论:-) – Steffen 2010-02-23 12:52:54

成本的一个重要因素是外键引用的索引大小 - 如果它很小并且经常使用，性能影响将可以忽略不计，较大和较少使用的索引会产生更大的影响，但是如果您的外键反对聚集索引，它仍然不应该是一个巨大的打击，但@Ronald布曼是正确的 - 你需要测试以确保。

来源

2010-02-23 22:29:40

这是一个政治问题，而不是技术问题。如果您的项目管理人员在维护数据完整性方面看不到任何价值，您需要参与不同的项目。

如果你的老板还不知道或关心你有成千上万的无效参考资料，他不会因为你告诉他而开始关心它。我同情这里的其他海报，他们试图通过与好斗作斗争来做到“正确的事情”，但之前我已经尝试了很多次，在实际操作中它不起作用。大卫和歌利亚的故事使人很好的阅读，但在现实生活中，这是一个失败的主张。

来源

2010-10-20 14:36:26

我同意@Dave在这里，但我鼓励你继续打好反抗。不幸的是，有时管理层担心他们（显然，虽然我们轻声说）不理解。这不仅使公司花费美元花费时间来纠正首先不需要发生的问题，而且阻碍了那些实际上最擅长设计这些解决方案的人的创造力和动态解决方案。我保留“永不言败”的态度，直到给出或证实了坚实的证据......对我的上级的恼怒...... – 2015-05-19 21:53:41

在SQL Server中使用外键有严重的性能下降吗？

回答

相关问题