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

Question

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

但是，这也始终需要注意，传输的数据仍然是传输的数据，并且仅仅因为您进行的查询较少并不意味着传输的数据是免费的。

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

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

显然，这种关系会因数据库规模增大等因素而发生变化，从而变得有些个性化，但这种个性化肯定不会导致无法绘制出广泛的景观？

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

Answer 1

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

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

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

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

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

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

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

1. 从订单表头表中检索订单列表
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. 在网格中显示结果。