在优化数据库查询时，查询数量和查询大小到底是什么关系？

Question

为了优化应用程序速度，每个人总是建议将应用程序对数据库进行的查询次数降到最低，将它们合并到更少的查询中，以便尽可能检索更多的查询。

然而，这也总是伴随着一个警告，即传输的数据仍然是传输的数据，并且仅仅因为您进行的查询较少并不意味着传输的数据是免费的。

我所处的情况是，我可以在查询上过度包含，以减少查询的数量，并简单地删除应用程序代码中不需要的数据。

对于每个查询的成本，是否有任何类型的经验法则，以了解何时优化查询数量与查询大小？我试着在谷歌上搜索客观的性能分析数据，但令人惊讶的是，我找不到任何这样的东西。

显然，这种关系会随着一些因素的变化而改变，比如当数据库的大小增加时，使其有点个性化，但这种个性化肯定不会如此个性化，以至于无法绘制出广义的景观？

我正在寻找一般的答案，但为了它的价值，我在Heroku.com上运行了一个应用程序，这意味着使用Postgres数据库的Ruby on Rails。

Answer 1

我坚定地站在“只在你需要的时候才得到你需要的东西”阵营。

检索可能需要或不需要的额外行(比方说，在加载订单摘要屏幕时检索完整的订单详细信息，以防用户向下钻取)只会导致更复杂的查询，可能会连接大多数时间不会使用的表。

作为DBA，最难优化的查询是将大量表连接在一起的查询。

检索额外的列并不是很糟糕，但有时服务器可以直接从“覆盖索引”中检索几个键列，而不必从基表中检索所有列。

我认为你所听到的建议的关键是，当你可以一次获得所有数据时，不要进行不必要的往返，而不是听起来像是在说“获取额外的数据，以防万一”。

开发人员习惯于将所有东西“模块化”，最终得到一个最终的web页面，对数据库进行数百甚至数千次调用，只加载一次web页面，这一点并不少见。我们有一个内部的商业产品，我们已经测量到，单个操作对数据库的调用超过50,000次。

举个例子(有点人为的)，假设您有一个"Order Summary“页面，其中包含一个"order total”字段，它是"Order Detail“表中所有项目的总和。错误的方法是：

对于每个订单，通过orders table

• Programatically

• 从order Header table

• Programatically循环中检索订单列表，执行查询以检索所有Order detail records

• Programatically将订单项目相加以获得总数，该总数显示在网格

中

听起来很疯狂，对吧？这比你想象的要普遍得多，特别是当你把数据绑定逻辑构建到单独的web组件中时。效率更高：

1. 对数据库进行一次调用，该查询类似于：

选择oh.OrderID，oh.OrderDate，SUM(od.LineTotal) as OrderTotal FROM OrderHeader oh INNER JOIN OrderDetail od on oh.OrderID =oh.OrderID the result in the grid。

Answer 2

如果您正在寻找一条经验法则:尽可能在数据库查询中进行过滤、排序和分页。数据库针对这些类型的操作(集合操作)进行了优化。

应用程序代码最好保留为真正的业务逻辑(以及显示逻辑等)。