2

我已经阅读了一些相关的问题，但没有找到与我的问题相关的细节。

如果我有一个不会更改的稳定应用程序，并且它已经过彻底测试并在野外使用......人们可能会考虑删除数据库模式中的引用完整性/外键约束，以提高性能。

在不讨论这样做的缺点的情况下，有谁知道一个人可能会体验到多少性能优势？有没有人这样做并体验到明显的性能优势？

4

7 回答 7

3

好处（无论多么小）对坏处来说微不足道。

如果性能有问题，请检查索引。扔更多的硬件。有许多技术可以提高性能。

我知道你说过不要提及缺点 - 但你应该考虑它们。数据是非常宝贵的资产，确保其有效性可以让您的业务继续发展。如果数据变得无效，您将面临一个巨大的问题来修复它。

于 2013-08-04T04:04:37.413 回答
3

根据我使用 Oracle 的经验：

外键为优化器提供信息（“您将在此连接上找到一个匹配项”），因此删除这些可能会导致（不是那么）有趣的事情发生在您的执行计划中。

外键确实会执行检查，这会降低性能。我已经看到那些在批处理上消耗了大量执行时间（一天中大部分时间运行的作业的时间），导致我们使用延迟约束。

由于删除外键会改变语义（想想级联，认为依赖于无法删除被其他东西引用的主条目的应用程序，至少在并发访问的情况下）我只会在外键时考虑这样的步骤被证明在这个应用程序中占主导地位。

于 2013-08-04T04:31:09.023 回答
2

试图在性能和有效性之间做出决定就像选择你宁愿没有哪只手臂。正如其他人所指出的，有更好的方法来解决性能问题（如索引优化、硬件、查询调整）。在任何设计良好的数据库系统中，降低引用完整性对性能的影响应该是最小的。

于 2013-08-04T05:45:26.680 回答
1

它会因应用程序而异。所以“多少”将是一个相对的术语。插入或删除记录时会带来性能优势。

因此，如果您有大量需要时间的插入或删除操作，那么它可能会有所帮助，但即使您的应用程序稳定，我也不建议您放弃它，因为在未来的开发中这可能会导致大问题。

于 2013-08-04T03:57:05.043 回答
1

有人可能会考虑删除数据库模式中的引用完整性/外键约束，以提高性能... [是否] 任何人都知道一个人可能会体验到多少性能优势

您没有向我们提供有关您的数据库架构或如何使用它的信息，所以我会保守一点，估计您的性能收益可能在 ±∞% 之间（给予或接受）。

从不必检查外键的角度来看，删除外键可以提高性能。

从查询计划生成无法信任它们并且无法采用与信任它们时相同的快捷方式的角度来看，删除外键会降低性能。请参阅你能相信你的约束吗？对于 SQL Server 示例。

外键不仅仅具有性能影响（例如ON DELETE CASCADE）。因此，试图删除它们以提高性能而不考虑您要删除的确切功能充其量是幼稚的。

于 2013-08-04T04:34:55.840 回答
1

在这个决定（或者可能是大多数/所有决定）的“只谈论性能收益而不是缺点”的背景下，这并不是一个真正公平的问题。由于您不能在没有缺点的情况下拥有优点，因此您需要了解两者的全部程度才能做出真正明智的决定。对于这个特定的问题，由于充其量只有一个好处（我说“充其量”，因为性能增益并不像大多数人想相信的那样有保证），那么如果我们不能谈论，我们就没什么可讨论的了关于缺点（但我们至少可以从好处开始:)。

好处：

  • 性能：删除外键可以让您在 DML 语句（INSERT、UPDATE 和 DELETE）上获得性能提升，但任何细节都高度依赖于相关表的大小、索引、使用模式（多久行已更新并且任何 FK 字段都可更新；插入和/或删除行的频率）等。虽然一些最佳实践问题可以说“几乎总是”具有性能提升，但对性能的任何影响都与任何变化只能通过测试来确定。关于与删除 FK 相关的典型性能提升，在您进入相对大量的行（如数百万或更多）和批量操作之前，您不太可能看到这一点。

缺点：

  • 性能：大多数人不会期望看到移除 FK 会对性能产生负面影响，但它很可能会发生。我不确定所有 RDBMS 是如何工作的，但 Microsoft SQL Server 中的查询优化器使用 FK（启用和受信任）的存在来缩短表之间的某些操作。没有正确定义 FK 会阻止优化器获得额外的洞察力，有时会导致查询速度变慢。

  • 数据完整性：数据库的主要职责是确保数据完整性。性能是次要的（即使非常接近）。你永远不应该为了一个优先级较低的目标而牺牲主要目标，特别是因为性能提升可以通过其他方法来实现，例如：索引、更多/更快的 CPU、更多/更快的 RAM 等。一旦你的数据是坏的，你可能无法纠正它。考虑到这一点：

    • 永远不要相信应用程序是“稳定的”或不会改变的。除非软件已经过时并且没有人有源代码来进行更改，否则它很可能会更改。
    • 不要相信你已经发现了代码中的所有错误，无论你认为它是多么“经过彻底测试”。该应用程序现在可能看起来很稳定，但谁说以后不会发现问题。如果您的应用程序中有超过 10 行代码，那么它是否 100% 没有错误是值得怀疑的。
    • 即使应用程序代码没有改变，你能保证不会针对数据库编写其他应用程序代码吗？如果这是让您无法控制的软件（即不是 SaaS），您是否可以阻止任何安装它的人编写他们自己的自定义代码来添加他们想要但在您的应用程序中未提供的功能？它发生了。甚至在 SaaS 公司中，其他部门也可能会尝试针对数据库编写工具（例如需要执行操作以帮助客户的 Support）。任何考虑删除 FK 的人都可能没有设置权限/安全性来防止此类事情发生。

  • 修复/更新的能力：该应用程序现在可能“稳定”，但公司经常改变方向和决策。FK 为数据存在的规则提供指导。即使现在没有发生数据完整性问题，如果有时间应用程序将添加新功能（或修复错误），没有定义 FK 将更有可能由于缺乏“文档”而引入错误“这将由 FK 提供。

于 2013-08-04T04:38:20.323 回答
0

参照完整性约束可能 [在某些数据库中，而不是 SQL Server 中] 自动在这些 FK 上创建索引；在这些条件下的查询中提供更好的性能。

这些索引通常有助于查询性能，从而可能大大提高效率。它们还为优化器提供附加信息，从而实现更好的查询计划。

如果性能是一个问题，那么在删除引用完整性之前，我会考虑许多其他事情（缓存、准备好的 stmts、批量插入）。但是，如果您有大量的活动索引并且在插入速度方面达到了严重的限制，那么它可能会被视为最后的选择。

于 2013-08-04T04:08:00.717 回答