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

Question

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

但是，由于历史原因，我们的 DBA 普遍不喜欢笛卡尔积。

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

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

更新 :

这些是类似的问题，但它们没有解释为什么或何时 Oracle 更喜欢 MJC超过常规 MERGE JOIN :

Why does this query result in a MERGE JOIN CARTESIAN in Oracle?

Why would this query cause a Merge Cartesian Join in Oracle

Answer 1

是的，提到笛卡尔连接通常会让 DBA 心跳加速。由缺少连接条件引起的笛卡尔连接绝对是一个处理起来很痛苦的事情——这些连接类型会“炸毁”临时空间并导致所有类型的警报响起。

我在 Oracle 的 11g 官方文档中没有找到关于这个特定连接方法的任何内容，但我确实在他们的支持数据库中找到了很多关于它的问题的文章。在过去的几周里，我已经追查了其中的一些，这就是我的发现。

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

确定此估计行数与实际行数是否是这种情况的最佳方法是运行查询并查看其执行计划统计信息。您提到您使用的是 11g - 使用 SQL 监控功能。此功能的输出将显示您在执行计划的每个步骤上花费了多少时间。它还会向您显示估计行数与实际行数。您正在寻找 MJC 输入的估计行数与实际行数之间的巨大差异。

SQL 监控可通过 OEM/DB Control 获得，或者您可以使用 API(搜索 DBMS_SQLTUNE.REPORT_SQL_MONITOR)。可以使用带有查询的 GATHER_PLAN_STATISTICS 提示收集相同类型的信息，然后使用 DBMS_XPLAN 生成报告...详细信息是 here要做到这一点。

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

如果您需要一把大锤子，则有一些隐藏参数允许/禁止使用 MJC。它们可以在数据库级别、 session 级别或查询级别(使用提示)实现。我将把参数名称留给读者作为练习，因为 Oracle 的官方立场是它们只能在支持人员的指导下使用。不要告诉他们，但在尝试获取对象统计信息以进行协作失败后，我已经成功地使用 OPT_PARAM 提示在查询级别消除了 MJC。