战 术 规 避 动 作 执行计划与 _optimizer_cbqt_or_expansion

现象：
升级到12.2以后，原先的执行计划可能会因为以下原因改变：

语句中有OR，执行计划中能看到 CONCATENATION 这样的operation。

原因：
12.2引入了基于成本的OR转换（明明11g就有了呀），导致语句性能较差

规避方法：
 _optimizer_cbqt_or_expansion=false
或
在你的语句种使用 USE_CONCAT 这个hint
或
设置 optimizer_features_enable='12.1.0.2'


参考：
Bad Execution Plan With OR Query After Update To 12.2.0.1 (Doc ID 2536570.1)

另外一种写法
select /*+ OPT_PARAM('_optimizer_cbqt_or_expansion','false') */ count(0) from ...



深入一点的知识：什么叫cbqt？

cost base query transformation
基于成本的查询转换 (CBQT)
CBQT 是一种修改查询并根据各种选项的相对成本决定最佳修改的技术。在这个过程中，它考虑了几种语义等价的查询形式，并选择成本最低的形式。

由于每个转换都需要创建查询的副本，然后需要计算该副本的成本，因此转换在内存使用和 CPU 方面是一项相对昂贵的操作，这反过来可能会增加优化器生成计划所需的时间.

在各种 Oracle 版本和 11g 尝试对一长串操作进行成本转换时，转换的范围有所增加。早期版本使用基于查询结构属性的启发式（或基于规则的）转换，但不考虑这些操作的成本。假设是这些转换总是比原始转换的性能更高，但事实并非如此。


可能英文版看着更舒服：



由参数_OPTIMIZER_COST_BASED_TRANSFORMATION来控制转换，可以选择 "exhaustive"穷举, "iterative"迭代, "linear"线性, "on"开, "off"关，从而对各种转换的成本进行控制。

但是，

但是此参数也会有些bug



在11.2.0.4 中cbqt相关隐含参数：


19.10 中的cbqt：


改一下试试：
又变了，出来个两端、贪心。

参考：
基于优化器成本的查询转换 (Doc ID 1082127.1)