2010-04-11 100 views
14

我正在构建Ruby on Rails 2.3.5应用程序。默认情况下,Ruby on Rails不提供外键约束,所以我必须手动完成。我想知道引入外键是否会降低数据库端的查询性能,使其不值得做。在这种情况下性能是我的首要任务,因为我可以检查数据与代码的一致性。总的来说,你的建议是什么?你推荐使用外键吗?你如何建议我应该衡量这一点?向MySQL引入外键是否会降低性能

+0

考虑到对使用连接的表间选择查询的影响,外键实际上对性能有积极影响。我不确定它是否会产生负面影响。 – Hanseh 2010-04-11 19:32:39

+1

嘿,这个问题的三个最佳答案是“性能好处”,“没有区别”,“性能损失”。 – 2013-03-05 04:15:40

回答

15

假设:

  1. 您已经使用支持FKS存储引擎(即:InnoDB的)
  2. 你已经对列的索引参与

然后我猜你会通过让MySQL强制执行完整性来获得更好的性能。毕竟,执行引用完整性是数据库引擎优化的功能。编写你自己的代码来管理Ruby中的完整性会比较慢。

如果您需要从MyISAM迁移到InnoDB以获取FK功能,则需要考虑两个引擎之间性能的折衷。

如果您还没有指示,您需要决定是否需要它们。一般来说,如果您的读取次数多于写入次数,您需要(需要,甚至是)指示。

将FK堆叠在当前索引的东西上应该会比在应用程序代码中实施这些类型的检查造成的整体性能降低更少。

5

一般来说,更多的键(外键或其他键)会降低INSERT/UPDATE性能并提高SELECT性能。

数据完整性的附加好处很可能只是总是值得您添加外键所带来的性能下降。如果一个快速应用程序中的数据是垃圾(丢失部分或其他),它有什么好处?

发现了类似的查询这里:Does Foreign Key improve query performance?

3

您应该定义外键。一般来说(虽然我不知道关于mySQL的具体情况),但对查询没有影响(当有优化器,如Oracle中的基于成本的优化器时,它甚至可能会产生积极影响,因为优化器可以依靠外键信息选择更好的访问计划)。 根据对插入和更新的影响,可能会产生影响,但您获得的好处(参照完整性和数据一致性)远远超出了对性能的影响。当然,你可以设计一个根本不会执行的系统,但主要原因不会是因为你添加了外键。当您决定使用其他语言时,或者因为业务规则稍有改变,或者因为新的程序员加入了您的团队等,对维护代码的影响远远大于性能影响。 然后,我的建议是肯定的,去定义外键。您的最终产品将更加健壮。

1

两点:
1.您确定在应用程序级别检查完整性在性能方面会更好吗?
2.运行自己的测试 - 测试FK对性能有积极或消极影响应该几乎微不足道。

3

使用外键是一个好主意,因为这可以确保数据的一致性(不需要孤行和其他不一致的数据问题)。

但是在添加外键的同时确实会引入一些性能打击。假设你使用INNODB作为存储引擎,它使用PK的聚集索引,其中数据与PK一起存储。要使用二级索引访问数据,需要通过二级索引树(其中节点包含PK),然后再通过聚簇索引传递数据以实际获取数据。所以涉及涉及FK的父表上的任何DML将需要两次通过子表中的索引。当然,性能影响取决于数据量,磁盘性能,内存限制(缓存的数据/索引)。所以最好用目标系统来衡量它。我想说测量它的最好方法是使用您的样本目标数据,或至少为您的系统提供一些有代表性的目标数据。然后尝试运行一些有和没有FK限制的基准。编写客户端脚本,在两种情况下都会生成相同的负载。但是,如果您手动检查FK约束,我建议您将其保留为mysql并让MySQL处理它。