CBO奇谈怪论——1

本文旨在帮助您理解优化器为什么做出了一个特定的选择，为什么这个选择(从您的角度来看)是一个糟糕的选择，以及您可以做些什么来帮助优化器找到一个更好的计划，或者颠覆优化器并强制执行一个更好的计划。

这是一系列笔记中的第一篇，旨在帮助您理解优化器为什么做出了一个特定的选择，为什么这个选择(从您的角度来看)是一个糟糕的选择，以及您可以做些什么来帮助优化器找到一个更好的计划，或者颠覆优化器并强制执行一个更好的计划。

如果您想知道我为什么选择区分“帮助优化器”和“颠覆优化器”，请考虑以下示例。

• 当您知道嵌套循环以相反的顺序连接会更好时，查询以错误的顺序连接两个表，因为您知道您想要的数据是非常好的聚集，并且有一个非常好的索引可以非常有效地访问这些数据。您检查表首选项，发现表缓存块首选项(参见结束注释)的默认值为1，因此您将其设置为16，并收集表上索引的最新统计信息。甲骨文现在认识到这一指数的有效性，并相应地改变计划。
• 优化器对查询做了一个惊人的转换，在连接到其他几个表之前聚合一个表，当您期望它在聚合之前使用连接来消除大部分数据时。经过一点调查，你发现设置隐藏参数_optimizer_distinct_placement到错误的阻止这一切发生。
  您可能会发现这种区分不必要的繁琐，但我会将第一个示例称为“帮助优化器”——它为优化器提供了一些关于您的数据的真实信息，这可能会在许多不同的语句中导致更好的决策——而第二个示例“颠覆优化器”——您粗暴地迫使它不走您不喜欢的路径，但同时您可能已经阻止了该功能以其他方式或其他查询出现。当然，您可能已经通过使用opt_param()提示只对这一个查询应用限制，尽管如此，如果您设法帮助优化器而不是限制它，那么有可能有一个更好的查询计划在查询的其他某个点使用该功能。

优化器有什么问题

很可能大多数文章都是基于解释执行计划，因为这些内容告诉我们优化器在执行语句时会发生什么，在执行计划中有三个关键方面需要考虑-

数字(尤其是费用 和行)，
计划的形状，
谓词信息。
我想用这张便条就这三点中的第一点谈几点。

• 首先，对执行计划的任何一行的估计是“每次开始”线的；在语句过程中，执行计划的某些行会被多次调用。在许多情况下行计划中某一行的估计将决定计划中其他行的执行次数——所以对“多少数据”会加倍，成为对…的错误估计“多少次”，这导致了一个在纸面上看起来高效但在运行时做了太多工作的计划。计划中看起来有点低效的一行如果只执行一行可能没问题，如果执行一百万次，看起来非常高效的一行可能是一场灾难。能够阅读计划并发现优化器对以下方面的错误估计行是一项关键技能——优化器产生不良估计有许多原因。能够发现不良估计在很大程度上取决于对数据的了解，但是如果您知道优化器产生不良估计的一般原因，那么当错误出现时，您就有了识别和解决错误的开端。
• 第二-Cost 与…同义时间。对于给定时刻的给定实例，优化器为费用声明(或声明的子部分)和时间优化器报告的。对于许多系统(那些没有运行校准_io 程序)时间 仅仅是费用乘以优化器认为满足单个块读取请求所需的时间费用是优化器对满足语句的输入/输出要求的估计，引入了一个模糊因子来识别这样一个事实，即“单块”读请求应该比“多块”读请求在更短的时间内完成。一般来说，优化器会考虑一个语句的许多可能的计划，并选择具有最低估计成本的计划——但是这个规则至少有一个例外，并且优化器中有许多这样的缺点是不幸的有效的其估计的原因成本/时间很穷。当然，您会注意到，Oracle为时间 列只精确到秒，当单个块读取通常在几毫秒范围内操作时，这不是特别有用。

优化器的任务在很大程度上归结为:

• 我需要的数据量和分布是多少
• 有哪些访问路径，有哪些浪费，可以获得这些数据
• 我要花多少时间在输入输出读取(也可能丢弃)数据上来提取我想要的位

当然，还有其他考虑因素，如排序所需的CPU数量、作为排序或散列连接的输入/输出的可能性、处理到远程系统的往返时间以及基本主题上的RAC变化。但是对于许多声明来说，驱动力的问题是“多少数据”和“多少(真实)输入/输出”会导致糟糕的、潜在的灾难性的执行计划选择。在下一篇文章中，我将列出优化器产生错误的容量和时间估计的所有不同原因(当时我能想到)。

参考资料成本与时间

• 成本就是时间
• 成本–再次
• 成本是时间——又一次

参考资料表缓存块以下内容:

• 初始介绍。
• RAC系统的另一个想法。
• 用法示例(在“更新[2015年12月11日”中)
• 与创建索引和索引重建相关的当前错误

原文链接：http://www.oaktable.net/content/cbo-oddities-%E2%80%93-1