Sql 查询成本与执行速度的关系+；相似

我的部门最近被我们的IT部门斥责（很好），因为我们的查询很有可能破坏数据库的稳定和/或崩溃，所以运行查询的成本非常高。我们都不是DBA的；我们只是针对数据库编写和执行查询的研究人员，我可能是唯一一个在谴责之前看过解释计划的人

我们被告知，查询成本超过100应该是非常罕见的，而成本超过1000的查询永远不应该运行。我遇到的问题是，成本似乎与执行时间没有关联，而且我在尝试优化查询时正在失去效率

例如，我有一个查询，它在5秒内执行，开销为10844。我重写了查询以使用包含我需要的大部分信息的视图，并将成本降低到109，但是新查询检索相同的结果，需要40秒才能运行。我在这里发现了一个问题，并给出了可能的解释：

那个问题使我想到了答案。我尝试在cost 10884查询中使用

/*+no_parallel*/

，但成本没有变化，执行时间也没有变化，因此我不确定并行性是否是执行时间更快但成本更高的原因。然后，我尝试使用

/*+parallel（n）*/

提示，发现

n

的值越高，查询的成本越低。在cost 10844查询中，我发现

/*+parallel（140）*/

将成本降低到97，而执行时间略有增加

这似乎是一个理想的“欺骗”，以满足我们IT部门提出的要求，但后来我读到：

这篇文章有这样一句话：

并行执行可以使单个操作利用所有系统资源

因此，我的问题是：

即使我在降低成本，但通过使用具有高度并行性的

/*+parallel（n）*/

提示，我是否真的给服务器资源带来了更大的压力

---

假设没有并行性，执行速度比成本更能衡量所使用的资源吗？

DBA给您的规则没有多大意义。担心为查询报告的成本很少有成效。首先，您无法直接比较两个不同查询的成本--一个成本为数百万的查询可能运行得非常快，消耗的系统资源非常少另一个成本为数百的查询可能运行数小时，使服务器崩溃。其次，成本是一种估算。如果优化器对成本做出了准确的估计，这就意味着它已经提出了最佳查询计划，这意味着您不太可能在使用较少资源的情况下修改查询以返回相同的结果。如果优化器对成本做出了不准确的估计，这强烈地意味着它提出了一个糟糕的查询计划，在这种情况下，所报告的成本与您提出的任何有用的指标都没有关系。大多数情况下，您试图优化的查询是优化器生成错误查询计划的查询，因为它错误地估计了各个步骤的成本

通过使用可能改变或可能不改变查询计划的提示来欺骗优化器（例如，取决于并行性的配置方式）不太可能解决问题--这很可能会导致优化器的估计不太准确，并且更可能是它选择的查询计划消耗的资源远远超过它需要的资源。例如，具有高度并行性的

parallel

提示将告诉Oracle大幅降低完整表扫描的成本，这使得优化器更有可能选择完整表扫描而不是索引扫描。这很少是DBA希望看到的

如果您要寻找一个指标来判断查询计划是否合理，我会使用逻辑I/O的数量。逻辑I/O与实际查询性能以及查询消耗的资源量有很好的相关性。查看执行时间可能会有问题，因为它会根据缓存的数据发生显著变化（这就是为什么查询在第二次执行时运行得更快），而逻辑I/O不会根据缓存中的数据发生变化。它还允许您根据查询处理更改所需的行数调整期望值。例如，如果您正在编写一个需要聚合100万行数据的查询，那么它所消耗的资源应该远远超过一个需要从没有聚合的表中返回100行数据的查询。如果您考虑的是逻辑I/O，那么您可以轻松地根据问题的大小调整您的期望，以确定查询的实际效率

例如，在克里斯蒂安·安托格尼尼（Christian Antognini）的《圣经》（第450页）中，他给出了一条非常合理的经验法则

• 返回/聚合的每行5次逻辑读取可能非常好
• 返回/聚合的每行10次逻辑读取可能就足够了
• 返回/聚合的每行20多个逻辑读取可能效率低下，需要进行调优

具有不同数据模型的不同系统可能需要稍微调整存储桶，但这些可能是良好的起点

我的猜测是，如果您是不是开发人员的研究人员，您可能正在运行需要聚合或获取相对较大数据集的查询，至少与应用程序开发人员通常编写的查询相比是这样。如果您正在扫描一百万行数据以生成一些聚合结果，那么您的查询自然会消耗比应用程序开发人员多得多的资源，因为应用程序开发人员的查询正在读或写一个handfu