Oracle CBO何时选择执行"merge join cartesian“操作？

Question

有时，甲骨文似乎更喜欢使用MERGE JOIN CARTESIAN操作，而不是常规的MERGE JOIN。了解数据并查看具体的执行计划，我可以看到这个操作通常不是一个问题，因为一个连接的实体只能返回手头查询中的一个记录。

然而，由于历史原因，我们的DBA普遍厌恶笛卡尔产品。

因此，我希望更好地分析这些案例，并在我的论证中得到文档的支持。是否有任何关于查询转换和CBO的官方Oracle文档，在这些文档中，我可以理解甲骨文喜欢MERGE JOIN CARTESIAN (或类似的)操作的情况吗？

在本例中，我使用的是Oracle 11g (11.2.0.2.0)

更新

这些都是类似的问题，但它们并没有解释甲骨文为什么或何时更喜欢MJC而不是普通的MERGE JOIN

• 为什么这个查询会导致Oracle中的合并加入笛卡儿？
• 为什么此查询会导致Oracle中的合并笛卡儿连接？

Answer 1

是的，提到笛卡尔的加入通常会让DBA的心跳加速。由于缺少连接条件而引起的笛卡尔连接肯定是一种痛苦的处理--这些连接类型可以“炸毁”临时空间，并导致所有类型的警报响。

我没有在Oracle的官方11g文档中找到关于这个特定联接方法的任何东西，但是我确实在他们的支持DB中找到了很多关于它的问题的文章。在过去的几周里，我已经找到了其中的几个，下面是我的发现。

MJC的来源是CBO优化。MJC是一种优化，当被连接的结果集的基数较低时，它工作得很好。当优化器没有正确估计作为连接输入的一个或多个结果集的基数时，就会出现这个问题。如果估计的行数=1(或者是一个较低的数目)，但是结果集的实际行很大，那么优化器仍然可以选择MJC，从而得到一个次优计划。这是轻描淡写的。我遇到了问题，这种情况发生和查询运行了数日，但没有完成。在使CBO重回正轨之后，他们只用了几秒钟，而不是几个小时或几天。

最好的方法是运行查询并查看其执行计划统计信息，以了解这个估计行与实际行之间的关系。您提到了您正在使用11g -使用SQL监视功能。此特性的输出将显示您在执行计划的每一步上花费了多少时间。它还将显示估计行与实际行之间的关系。您正在寻找MJC输入上的估计行与实际行之间的巨大差异。

Monitoring可以通过OEM/DB控件获得，也可以使用API (搜索DBMS_SQLTUNE.REPORT_SQL_MONITOR)。使用GATHER_PLAN_STATISTICS提示和查询可以收集相同类型的信息，然后用DBMS_XPLAN生成报告.细节是这里来做的。

那么如何摆脱它呢？尝试解决对象统计问题。一旦CBO知道它真正处理的是数百、数千或数百万条记录作为连接的输入，而不是“1”，那么它应该选择一个更适合于数据集的联接方法，而不是选择MJC。说起来容易做起来难，关于这个主题的书已经写好了，但至少要查看基本知识--确保查询中涉及的所有表至少都有统计数据。如果在where子句中应用了多列表达式，也可以利用补充统计数据。

如果您需要一个大锤子，有一些隐藏参数允许/不允许使用MJC。它们可以在数据库级别、会话级别或查询级别(使用提示)实现。我将把参数命名作为读者的练习，因为Oracle的官方立场是，它们只能在支持的指导下使用。不要告诉他们，但在试图获得对象统计信息以配合失败之后，我已经成功地在查询级别消除了MJC，并给出了OPT_PARAM提示。