Oracle 自动跟踪与解释

Question

我的团队使用 Oracle 11 和 SQL Developer。我最近一直在很大程度上依赖于解释计划来尝试确定解决各种问题的最有效方法。最近，一位同事指出，解释计划并不总是准确反映数据库中实际发生的情况，自动跟踪是更好的指示，因为查询实际上是针对数据运行的。

测试查询，我得到以下结果

_________________________________
|      Method        |   Cost   | 
|--------------------|----------|
| Query A Explain    |  306,188 |
| Query A Autotrace  |  399,131 |
| Query B Explain    |   99,226 |
| Query B Autotrace  |  137,661 |
|____________________|__________|

使用自动跟踪时，查询 A 的成本增加了 30%，查询 B 的成本增加了近 40%。显然，我应该在这两种情况下都使用查询 b，但我不明白是什么导致它们不同。

Answer 1

SQL Developer 中的 Autotrace 从 v$sql_plan 获取计划，还从您的会话中获取统计信息，在运行查询之前和之后执行会话统计信息的增量。

解释计划询问数据库它认为该计划将用于您的查询。

你的同事是对的，他们可能会有很大的不同，你最好使用 AutoTrace 或我们在 4 及更高版本中显示缓存计划的新功能（解释计划按钮上的下拉控件使这些可用。）

Answer 2

有很多事情会导致实际计划与估计计划不同（如果你想深入研究杂草，有很多事情会导致实际计划的不同产生方法产生不同的结果但我会忽略它）。

最简单（也是最常见的）围绕绑定变量。如果我做EXPLAIN PLAN一个简单的查询，比如

SELECT COUNT(*)
  FROM my_table
 WHERE col1 = :1

Oracle 没有关于我可能传入什么值的信息，col1所以它做了一个非常通用的估计。例如，如果有 20 个不同的值，它可能会猜测查询需要访问表中 5% 的行。如果你真的执行这个语句并传入一个值，另一方面，Oracle 有更多的信息——它可能从直方图中知道你传入的值实际上需要它访问 7% 的行桌子。如果实际查询计划保持不变，那么cost由于预期的工作量增加了 40% ，因此增加 40%是完全合理的。

导致估计查询计划中的细节与实际查询计划中的细节不同的所有内容的完整列表以及这些事物如何交互的解释对于这种格式来说太长了（特别是因为很多项目变得非常复杂）迅速地）。在某些情况下，对象的统计信息丢失，例如，优化器必须对数据进行随机抽样以在编译时推断统计信息，每次编译查询时都会有所不同。在许多情况下，优化器具有某种反馈机制，该机制会在查询运行时启动，而在估计查询计划时则没有这种机制——它可能会根据可用资源选择一定程度的并行度, 它可能会改变排序的成本，具体取决于它可以获得多少 PGA 空间，这取决于如果操作检索的数据比预期的多得多或少得多，它可能能够改变进程的版本。对缓存的计划或尝试确保在实际编译查询时启动计划稳定性的不同技术有影响。