Oracle Sql查询的性能调整

嗨，团队，
我正在努力进行查询调整，以下是与之相关的详细信息，请对其进行分析和推荐。

SELECT *
FROM   (SELECT
       /*+ INDEX(A INDX14_TABLE1)  INDEX(B IDX51_TABLE2) */
              *
        FROM   TABLE1 A,
               Table2  B 
        WHERE  EXE.process_id = EXT.pin
               AND activity = :"SYS_B_0"
               AND ( status = :"SYS_B_1"
                      OR status IS NULL )
               AND status = :"SYS_B_2"
               AND process = :"SYS_B_3"
               AND ((( zone = :"SYS_B_4" )))
        ORDER  BY process DESC,
                  fork DESC)
WHERE  ROWNUM <= :"SYS_B_5" 
复制

上面的查询做31K的LIO，由于rownum，它带来10- 12行，这取决于ROWNUM传递的值，没有rownum，总行数是500〜600，由t LIO返回太高约30K

对于测试结果，我执行如下查询 :( 通过删除提示，它生成了类似的计划)

SELECT
       /*+ INDEX(A INDX14_TABLE1)  INDEX(B IDX51_TABLE2) */
              *
        FROM   TABLE1 A,
               Table2  B 
        WHERE  A.process = b.pin
               AND activity = :"SYS_B_0"
               AND ( status = :"SYS_B_1"
                      OR status IS NULL )
               AND status = :"SYS_B_2"
               AND process = :"SYS_B_3"
               AND ((( zone = :"SYS_B_4" )))
        ORDER  BY process DESC,
                  fork DESC
      
------------------------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name                    | Starts | E-Rows | A-Rows |   A-Time   | Buffers |  OMem |  1Mem | Used-Mem |
------------------------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                      |                         |      1 |        |      1 |00:00:00.52 |   31088 |       |       |          |
|   1 |  SORT AGGREGATE                       |                         |      1 |      1 |      1 |00:00:00.52 |   31088 |       |       |          |
|*  2 |   HASH JOIN                           |                         |      1 |  30154 |    160 |00:00:00.52 |   31088 |  1106K|  1106K| 2467K (0)|
|   3 |    TABLE ACCESS BY INDEX ROWID BATCHED| TABLE1                  |      1 |  30154 |    594 |00:00:00.01 |     372 |       |       |          |
|*  4 |     INDEX RANGE SCAN                  | INDX14_TABLE1           |      1 |   8898 |    594 |00:00:00.01 |      33 |       |       |          |
|*  5 |    INDEX FAST FULL SCAN               | IDX51_TABLE2            |      1 |    713K|   1075K|00:00:00.40 |   30716 |       |       |          |
------------------------------------------------------------------------------------------------------------------------------------------------------ 
复制

INDX14_TABLE1索引con列: 进程、活动、状态 (这些行过滤器从表1中带120行
注意: 他们的两个colun进程和process_id，这里使用的索引是有列 (进程，活动，状态)
IDX51_TABLE2: 引脚，区域
对于列区数据是偏斜的，但直方图不会受益
我的问题:
它应该在嵌套循环中执行，我不确定为什么它会在哈希联接中执行
还有其他方法来调整它


TABLE2带来了更多的行，但是从table1的行大约是120，那么它应该使用嵌套循环，这里的统计有问题吗？

这里真正重要的是图钉，区域上的索引在表2上有多 “好”。

可以说，正如您所说，我从table1返回了120行。这意味着120探针进入table2。如果IDX51_TABLE2是好的和选择性的，那么120探针可能并不昂贵。但是，如果指数不是很大，那么我们将 “不是很大” 乘以120。

您可以通过使用以下提示来自己测试性能:

领先 (a b)
使用索引 (b IDX51_TABLE2)

将表1 (a) 中的嵌套循环强制进入表2 (b)，并进行一些性能比较。

如果它确实更好，那就比使用大纲或sql计划管理来锁定计划要好。

如果它 * 不是 * 更好，那么您可能需要查看替代/修改的索引定义 (如果可能的话)。