外键可以损害查询性能

Question

正如我在本文中所理解的,在某些情况下,外键可以提高查询性能.

我听到了相反的说法,即由于参照完整性检查,外键实际上可能会损害查询性能.在哪种情况下(如果有的话)这是真的吗？

---

1)术语查询似乎具有误导性.我对各种表现处罚感兴趣.

2)是否有人对INSERT,DELETE或UPDATE语句的负面影响有任何实际数字(我知道这取决于特定的系统,但是,任何类型的真实世界测量都会受到赞赏)？

Answer 1

如果引用完整性需要外键,那么外键的存在应构成性能的基线

你不妨问一下,如果你不把座位放进去,一辆车可以走得更快 - 一辆造型良好的汽车包括座位,就像一个结构良好的数据库包括外键一样

Answer 2

我假设对于INSERT查询,约束 - 包括外键约束 - 会稍微降低性能.数据库必须检查您告诉它插入的内容是您的约束允许它插入的内容.

对于SELECT查询,外键约束不应对性能进行任何更改.

由于INSERTS几乎总是非常快,除了在边缘情况下,少量的额外时间将不会明显.(构建一个几千兆字节的数据库,您可能希望禁用约束,然后在以后重新启用,只要您确定数据是好的.)

Answer 3

外键可能会导致在子表中插入（或某些更新）或从父表中删除需要更长时间。然而，这是一件好事，因为它意味着确保数据完整性仍然存在。除非您不想拥有有用的数据，否则没有任何理由跳过使用外键。除非您有许多外键分配给同一个父表，或者您在一批中插入或删除许多记录，否则您通常不会注意到太大差异。此外，我注意到，用户在插入或删除中比在选择中更能容忍几秒钟的额外时间。用户也根本无法容忍不可靠的数据，而这些数据是没有外键约束的。

您需要对它们进行索引以提高选择查询的性能。

Answer 4

理论上,是的:数据写入需要验证约束.

在实践中,很少:除非另有测量和证明,否则您可以假设没有性能影响.绝大多数情况下,由于其他问题而出现性能问题:

• 错误的架构设计(缺少索引,错误的聚簇索引选择)
• 争用(阻塞),再次由于错误的架构设计(表扫描保证锁冲突)
• 糟糕的查询设计

在设计良好的架构和良好的查询上,约束的成本将开始以非常高的吞吐量出现.发生这种情况时,有预防措施.

我的2c:永远不要牺牲一些难以捉摸的表现目标的正确性限制.在非常罕见的情况下,当约束确实是问题时,有测量结果表明情况就是这样,并且俗话说:如果你不得不问它需要多少费用,你就买不起.如果你不得不问问约束是否有问题,你就不能删除它们(没有违法行为).