成本较低的 SQL 查询运行速度比成本高的查询慢答案

【问题标题】：SQL Query with lower costs runs slower than queries with way higher cost成本较低的 SQL 查询运行速度比成本高的查询慢
【发布时间】：2019-08-18 08:24:33
【问题描述】：

我对 DB2 数据库上的 SQL 查询运行了两个查询的执行计划。第一个查询的开销大约是380000，修改查询后用子查询替换了一些内连接，开销降到了312（注意：不是312000，只是312）

但是，在多次运行每个查询后，较大的查询平均运行得更快。这可能是什么原因？

【问题讨论】：

您的子查询是什么？它们是否涉及与 varchars 的比较？
如果这是一个 DB2 问题，为什么该问题标记为 Oracle？
可能是您的数据库统计数据过时，估计的成本有误。可能是高成本计划实际上可以在多个线程/内核上并行运行；所以正在做更多的工作，仍然使用更多的资源，但从你的角度来看仍然需要更少的时间。 SO评论或答案中有太多可能的原因。

标签： sql db2 sql-execution-plan

【解决方案1】：

对于任何使用基于成本的优化器的数据库，成本是一个估计值。如果估计正确，则查询成本和运行时间之间应该存在相关性。然而，有时，估计值还差得很远。通常，您更有可能查看优化器的估计值偏离的查询，因为当估计值偏离计划时很可能是坏的，查询将运行缓慢，并且有人正在要去抱怨。人们通常不会查看优化器估计正确的 99% 的查询。

在这种情况下，优化器的成本估算似乎与此相去甚远。这很可能是由于某些表、索引或列上的统计信息不正确造成的。当然，可能还有其他问题——它可能认为缓存中的行数非常少，或者磁盘 I/O 比实际成本高得多或低得多（即，您的 I/O 子系统承受着巨大的压力）并且速度很慢，或者您将所有内容都放在固态磁盘上，因此 I/O 非常快）。但我总是从查看统计数据开始。

【讨论】：