database - 在优化数据库查询时，查询次数和查询大小之间到底是什么关系？

Question

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

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

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

对于每个查询的成本有多少，是否有任何类型的经验法则来了解何时优化查询数量与查询大小？我曾尝试在 Google 上寻找客观的性能分析数据，但令人惊讶的是，我找不到任何类似的东西。

显然，这种关系会随着数据库规模的增长等因素而发生变化，从而使这种关系变得有些个性化，但肯定不会个性化到无法勾勒出广义的景观？

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

Answer 1

我坚定地支持“只在需要时获取所需的东西”阵营。

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

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

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

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

开发人员已经习惯于“模块化”所有内容，最终得到一个进行 数百 甚至 数千 调用的网页并不罕见到数据库加载网页仅一次。我们有一个内部商业产品，据我们测量，该产品可以超过 50,000 次调用数据库以执行单个操作。

举个例子(有点做作)，假设您有一个“订单摘要”页面，其中包含一个“订单总计”字段，它是“订单详细信息”表中所有项目的总和。 错误的方法是:

1. 从 Order Header 表中检索订单列表
2. 以编程方式遍历订单
3. 对于每个订单，执行查询以检索所有订单详细记录
4. 以编程方式将订单项相加以获得总数，该总数显示在网格中

听起来很疯狂，对吧？这比您想象的更常见，尤其是当您将数据绑定(bind)逻辑构建到单个 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. 在网格中显示结果。