求助：一个关于ORACLE索引的疑难杂症

anlinew

最初由 catchwo 发布
[B]这个sql是以Ec_Quantity_History Tb 驱动
不对，你仔细看上面分析的帖子[/COLOR]


1 IDX_EC_QUANTITY_HISTORY4 比 IDX_EC_QUANTITY_HISTORY1 过滤的结果多很多

不对，不加exists条件时走索引4过滤执行时间也很快[/COLOR]


2 然后加上一个NL

这个NL是如何执行的是个问题[/COLOR]

结果就是every slowly [/B]

anlinew

这个问题比较怪异，至少我从没遇到过，
虽然楼主给的信息严重不足，但可以讨论一下各种可能性

catchwo

0 这些表如果最近没有分析过其执行计划里的cost是不准确的！

这个sql是以Ec_Quantity_History Tb 驱动
不对，你仔细看上面分析的帖子
这个我搞错了


1 IDX_EC_QUANTITY_HISTORY4 比 IDX_EC_QUANTITY_HISTORY1 过滤的结果多很多

不对，不加exists条件时走索引4过滤执行时间也很快
这时不用NL，所以会很快

2 然后加上一个NL

这个NL是如何执行的是个问题
这是cbo根据cost来选则的
注意：
  NESTED LOOPS    /*+这个NL是怎么做的？*/        67    1    91
    SORT UNIQUE            35    1    52
     TABLE ACCESS BY INDEX ROWID    EC_ACC_FEE_BACK        35    1    52
      INDEX RANGE SCAN    IDX_EC_ACC_FEE_BACK11    "ZONE_CODE"='011301' AND "ACC_FEE_DATE" LIKE '200706%'    5    892   
    INDEX RANGE SCAN    IDX_EC_QUANTITY_HISTORY4    "ZONE_CODE"='011301' AND "REPORT_FORM_MONTH"='200706'    4

这里不是索引和索引进行NL，而是TABLE ACCESS BY INDEX ROWID    EC_ACC_FEE_BACK 的行集与IDX_EC_QUANTITY_HISTORY4进行NL


结果就是very slowly

anlinew

最初由 catchwo 发布
[B]
2 然后加上一个NL

这个NL是如何执行的是个问题
这是cbo根据cost来选则的
注意：
[php]
  NESTED LOOPS    /*+这个NL是怎么做的？*/        67    1    91
    SORT UNIQUE            35    1    52
     TABLE ACCESS BY INDEX ROWID    EC_ACC_FEE_BACK        35    1    52
      INDEX RANGE SCAN    IDX_EC_ACC_FEE_BACK11    "ZONE_CODE"='011301' AND "ACC_FEE_DATE" LIKE '200706%'    5    892   
    INDEX RANGE SCAN    IDX_EC_QUANTITY_HISTORY4    "ZONE_CODE"='011301' AND "REPORT_FORM_MONTH"='200706'    4

[/php]
这里不是索引和索引进行NL，而是TABLE ACCESS BY INDEX ROWID    EC_ACC_FEE_BACK 的行集与IDX_EC_QUANTITY_HISTORY4进行NL
这是怎么个走法？关联字段都不在索引列里

结果就是very slowly [/B]

不过有一点应该可以肯定
表的统计信息是不对的。。。

anlinew

NLJ

catchwo

1 TABLE ACCESS BY INDEX ROWID EC_ACC_FEE_BACK  已经返回的是EC_ACC_FEE_BACK  表的一个子集不是索引的子集（所有列都在每一行里）
2 对上面那个子集排序后（SORT UNIQUE）
3 与索引IDX_EC_QUANTITY_HISTORY4   的子集 进行NL

NL原理和两个嵌套循环类似
FOR(.....)
{
FOR(.....)
{
  .........
}
}


上面那个只是一个原理图----且不是十分正确

anlinew

最初由 catchwo 发布
[B]1 TABLE ACCESS BY INDEX ROWID EC_ACC_FEE_BACK  已经返回的是EC_ACC_FEE_BACK  表的一个子集不是索引的子集（所有列都在每一行里）

2 对上面那个子集排序后（SORT UNIQUE）
子集A

3 与索引IDX_EC_QUANTITY_HISTORY4   的子集 ( 子集B)进行NL

NL原理和两个嵌套循环类似
FOR(.....)
{
FOR(.....)
{
  .........
}
}


上面那个只是一个原理图----且不是十分正确 [/B]

如上绿字部分，子集A和子集B没有关系，如何NL？

你强调了EC_ACC_FEE_BACK  表的所有列，但这没用，没有做关联，索引IDX_EC_QUANTITY_HISTORY4   的字段在EC_ACC_FEE_BACK  表中有没有，是否同样的意义，对于ORACLE来说是未知的

所以，如果子集B是TABLE ACCESS BY INDEX IDX_EC_QUANTITY_HISTORY4    ROWID 后的结果倒是可能NL的，可从执行计划看，不是这样

catchwo

由于没有关联字段，所以此NL就是子集A和子集B的一个笛卡尔集。所以会very slowly 以下是个NL=笛卡尔集的图例

catchwo

如图：

anlinew

最初由 catchwo 发布
[B]由于没有关联字段，所以此NL就是子集A和子集B的一个笛卡尔集。所以会very slowly 以下是个NL=笛卡尔集的图例 [/B]

我也知道这样的NL只可能是笛卡儿集，只是奇怪为什么不干脆MERGE JOIN (CARTESIAN)呢，在不hint NL的情况下，我试了几个版本都无法模拟出楼主的情况
之前说的楼主的表统计信息错误并且乱加HINT应该是造成这个问题的原因，但就算信息错误，也不应该是NL啊