Oracle子查询性能

所以我有一张巨大的桌子，someid，someDate。。。。我需要将这个表的一个子集连接到另一个表。子集由以下内容确定：select*from SS where someID in select someID from SS where someDate在date1和date2之间

在Oracle XA data server上并行运行此操作时，执行需要很长的时间和临时空间，即使Oracle可以在SS表上实现99%的单元卸载效率，但子集查询仍会将大量数据带回数据库服务器，并与其他表连接

有没有办法提高效率？例如，Oracle不必发送回那么多数据，也不必利用更多的单元卸载效率

下面是查询计划

PLAN_TABLE_OUTPUT
Plan hash value: 3198983388

---------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                               | Name           | Rows  | Bytes | Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |
---------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                        |                |  1044K|   589M| 46101   (1)| 00:01:33 |        |      |            |
|   1 |  PX COORDINATOR                         |                |       |       |            |          |        |      |            |
|   2 |   PX SEND QC (RANDOM)                   | :TQ10003       |  1044K|   589M| 46101   (1)| 00:01:33 |  Q1,03 | P->S | QC (RAND)  |
|*  3 |    HASH JOIN BUFFERED                   |                |  1044K|   589M| 46101   (1)| 00:01:33 |  Q1,03 | PCWP |            |
|   4 |     PX RECEIVE                          |                |       |       |            |          |  Q1,03 | PCWP |            |
|   5 |      PX SEND HASH                       | :TQ10001       |       |       |            |          |  Q1,01 | P->P | HASH       |
|   6 |       NESTED LOOPS                      |                |       |       |            |          |  Q1,01 | PCWP |            |
|   7 |        NESTED LOOPS                     |                |   523K|   135M| 38264   (1)| 00:01:17 |  Q1,01 | PCWP |            |
|   8 |         SORT UNIQUE                     |                | 29402 |   401K| 13751   (1)| 00:00:28 |  Q1,01 | PCWP |            |
|   9 |          PX RECEIVE                     |                | 29402 |   401K| 13751   (1)| 00:00:28 |  Q1,01 | PCWP |            |
|  10 |           PX SEND HASH                  | :TQ10000       | 29402 |   401K| 13751   (1)| 00:00:28 |  Q1,00 | P->P | HASH       |
|  11 |            PX BLOCK ITERATOR            |                | 29402 |   401K| 13751   (1)| 00:00:28 |  Q1,00 | PCWC |            |
|* 12 |             INDEX STORAGE FAST FULL SCAN| SUPERSET_IDX1  | 29402 |   401K| 13751   (1)| 00:00:28 |  Q1,00 | PCWP |            |
|* 13 |         INDEX RANGE SCAN                | XU_SUPERSET_01 |    18 |       |     1   (0)| 00:00:01 |  Q1,01 | PCWP |            |
|  14 |        TABLE ACCESS BY INDEX ROWID      | SUPERSET       |    18 |  4644 |     2   (0)| 00:00:01 |  Q1,01 | PCWP |            |
|  15 |     PX RECEIVE                          |                |  2886K|   880M|  7834   (2)| 00:00:16 |  Q1,03 | PCWP |            |
|  16 |      PX SEND HASH                       | :TQ10002       |  2886K|   880M|  7834   (2)| 00:00:16 |  Q1,02 | P->P | HASH       |
|  17 |       PX BLOCK ITERATOR                 |                |  2886K|   880M|  7834   (2)| 00:00:16 |  Q1,02 | PCWC |            |
|  18 |        TABLE ACCESS STORAGE FULL        | POL_DTL        |  2886K|   880M|  7834   (2)| 00:00:16 |  Q1,02 | PCWP |            |
---------------------------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - access(SS.POL_ID=PD.POL_ID)
  12 - storage(IMPT_DT<=TO_DATE(' 2014-11-20 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND IMPT_DT>=TO_DATE(' 2014-10-28 
              00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
       filter(IMPT_DT<=TO_DATE(' 2014-11-20 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND IMPT_DT>=TO_DATE(' 2014-10-28 
              00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
  13 - access(SS.POL_ID=POL_ID)

Note
-----
   - Degree of Parallelism is 4 because of session

---

要改进此查询，您可能没有什么可做的。执行计划看起来相当不错：

好的对象索引似乎很适合查询，尽管没有完整的定义很难判断。 良好的基数估计行和实际行接近。这强烈暗示优化器做得很好，并且正在选择一个接近最优的计划。如果它能够正确估计行数，它将对访问路径、连接方法、连接顺序等做出明智的决定。即使时间估计很接近，但这是罕见的。看起来有很好的表格和系统统计数据。 单元卸载存储谓词和活动报告单元卸载意味着单元卸载正在按预期工作，至少一次。 并行性已并行处理大型对象。我没有看到任何明显的平行问题。 以下是一些改进的想法，但不要期望有大幅度的改进：

全表扫描强制进行全表扫描，而不是索引范围扫描，提示为-+no_indexsuperset XU_SUPERSET_01。如果多块读取用于完全扫描，单元卸载用于直接路径读取用于完全扫描，而不用于使用缓冲区缓存的索引范围扫描，则读取所有数据的完整表扫描可能比读取较少数据的索引范围扫描更有效。 覆盖索引如果完整表扫描不起作用，请使用包含所有返回和查询列的索引创建表的精简版本。这获得了全扫描多块IO、单元卸载的好处，但比全表小。 DOP越大，平行度DOP没有幻数。但根据我的经验，DOP的甜点几乎总是大于4。这可能会提高性能，但会使用更多资源。 重写查询？重新写入查询可能使智能扫描能够处理存储单元中的连接。试着改变

select * from SS where someID in 
  (select someID from SS where someDate is between date1 and date2)

到

这个新版本做了额外的工作。联接返回的行比需要的多，因此需要将它们区分开来。如果这意味着连接可以在存储单元中进行，那么额外的工作可能是值得的。我找不到一个很好的来源来说明什么样的处理可以被卸载，但至少有些类型的连接可以被卸载

---

选择*from SS where someID in选择someID from SS where someDate在date1和date2之间。这真的可以称为自连接吗？或者它是一个相关的子查询？我不知道这是否会改变优化器的某些功能。。。无论如何，如果没有查询计划，很难回答这样的问题。我认为select*from SS，其中someDate介于date1和date2之间，返回的结果与您的查询结果相同，所以我不太理解这一点，我添加了执行统计和计划。如您所见，有很多活动…请运行一个命令：在此处解释您的查询计划；然后运行SELECT*fromtabledbms_XPLAN.DISPLAY，最后请以文本格式将上次查询的结果复制到剪贴板，并将其粘贴到答案。图像很漂亮，但很难阅读。谢谢。我不知道如何从计划中保留表格格式。每次我复制/粘贴到这里，它都会丢失所有格式：如果右键单击图像，并在新选项卡中打开，它应该显示得非常清晰。我从Oracle Enterprise Manager中获取了这张快照。我认为它无法进一步改进。非常感谢。

select distinct ss1.*
from ss ss1
join ss ss2
    on ss1.someID = ss2.someID
     and ss2.someDate is between date1 and date2