在优化数据库查询时，查询数量与查询大小之间的关系究竟是什么？

Question

为了优化应用程序速度，每个人都建议尽量减少应用程序对数据库的查询次数，将它们合并为更少的查询，以便尽可能检索更多。

然而，这也始终需要注意的是，传输的数据仍然是数据传输，并且仅仅因为您减少查询次数并不能使数据免费传输。

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

对于每个查询有多少成本，知道何时优化查询次数与查询大小，是否存在任何类型的经验法则？我曾尝试使用谷歌来获取客观的性能分析数据，但令人惊讶的是还没有找到类似的东西。

显然，这种关系会随着数据库规模增长等因素的变化而变化，这使得这种关系变得个性化，但这肯定不是那么个性化，以至于无法得出广泛的景观意识？

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

Answer 1

我坚定地“只在你需要的时候得到你所需要的”阵营。

检索您可能需要或可能不需要的额外行（假设，在加载订单摘要屏幕时检索完整订单详细信息，以防用户向下钻取）只会导致更复杂的查询，可能会连接赢得的表大部分时间都不会使用。

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

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

我认为你所听到的建议的关键是不能进行不必要的往返，而你可以一次性完成所有这些，而不是听起来像是在说“获取额外的数据”以防你需要它。“

开发人员已经习惯于“模块化”所有内容，实际上最终得到的最终网页数百个甚至数千个来电并不奇怪到数据库加载网页一次。我们内部有一个商业产品，我们已经测量了超过50,000次调用数据库的单一操作。

举个例子（有些人为），假设您有一个“订单摘要”页面，其中包含“订单总计”字段，该字段是“订单明细”表中所有项目的总和。 错误的方法是：

1. 从订单表格中检索订单列表
2. 以编程方式循环执行订单
3. 对于每个订单，执行查询以检索所有订单明细记录
4. 以编程方式将订单项目相加以获得总计，这将显示在网格
中

听起来很疯狂吧？这比您想象的更常见，尤其是当您将数据绑定逻辑构建到单个Web组件中时。效率更高：

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

   SELECT oh.OrderID, oh.OrderDate, SUM(od.LineTotal) as OrderTotal
   FROM OrderHeader oh
   INNER JOIN OrderDetail od on oh.OrderID = od.OrderID
   

2. 在网格中显示结果。

Answer 2

如果您正在寻找经验法则：尽可能在数据库查询中进行过滤，排序和分页。数据库针对这些类型的操作（设置操作）进行了优化。

应用程序代码最好保留用于真正的业务逻辑（和显示逻辑等）。