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

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

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

我的情况是，为了减少查询的数量，我可以在查询中包含过多的内容，而只需删除应用程序代码中不需要的数据

对于每个查询的成本有多少，是否有任何类型的经验法则，以了解何时优化查询数量和查询大小？我曾尝试在谷歌上搜索客观的性能分析数据，但令人惊讶的是，我没能找到类似的数据

很明显，这种关系会因一些因素而改变，比如数据库的规模增大，这会使它有点个性化，但这肯定不是那么个性化，以至于无法描绘出广义的景观

---

我在寻找一般性的答案，但无论如何，我正在Heroku.com上运行一个应用程序，这意味着Ruby on Rails带有Postgres数据库。

如果你想寻找一条经验法则：尽可能在数据库查询中进行筛选、排序和分页。数据库针对这些类型的操作（集合操作）进行了优化

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

我坚定地站在“需要时只获取所需”阵营中

检索您可能需要或可能不需要的额外行（比如，在加载订单摘要屏幕时检索完整的订单详细信息，以防用户深入查看）只会导致更复杂的查询，可能会合并大部分时间不会使用的表

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

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

我认为你听到的建议的关键是，当你可以一次获得所有数据时，不要进行不必要的往返，而不是像你说的那样“获取额外数据以备不时之需”

开发人员已经习惯于“模块化”一切，最终生成一个对数据库进行数百次甚至数千次调用以加载网页一次的最终网页并不罕见。我们有一个商业产品，我们已经测量过，它在一次操作中向数据库发出了50000多个调用

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

从订单标题表中检索订单列表

以编程方式循环处理订单

对于每个订单，执行查询以检索所有订单详细信息记录

通过编程方式将订单项相加，得到显示在网格中的总额

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

对数据库进行一次调用，该调用将生成类似以下内容的查询：

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

在网格中显示结果

---

如果我没听错的话，就速度而言，传输数据的成本通常远远超过额外查询的成本？因此，在一个人为的例子中，假设我有一批100个大小合适的对象要检索，几乎总是这样的情况，运行100个单独的查询比单个查询检索101个（不需要额外的）？@williamjones不，一点也不正确。每次往返都有非常大的成本。关键是，如果您仍然需要数据，请尽可能少地使用它。如果你不知道你是否需要数据，那么等到你真的需要它。关于你的人为的例子，当然最好在一个查询中得到101行，而不是100个单独的查询。然而，在现实世界中，我发现开发人员进行一次查询来检索100000行，然后扔掉99900行更为常见。或者检索表的所有100列，然后只使用5。选择您最喜欢的人为示例：）