OR 条件使查询执行缓慢答案

【问题标题】：OR Condition making the query execution slowOR 条件使查询执行缓慢
【发布时间】：2012-05-10 18:19:25
【问题描述】：

我正在尝试执行一个带有 WHERE 子句的查询（在 Oracle SQL 中），如下所示：

    SELECT booking_line_id
FROM booking_line
WHERE    (booking_line_id in
  (SELECT sbli.booking_line_id
   FROM search_booking_line_index sbli,
     policy_record pr,
     policy_record_revision prr
   WHERE sbli.attribute_name = 2209
   AND sbli.policy_record_id = pr.policy_record_id
   AND pr.latest_revision_id = prr.policy_record_revision_id
   AND LOWER(prr.broker_reference) LIKE '%123%'));

执行计划：

|   0 | SELECT STATEMENT       |                        | 19027 |   334K|   455   (3)| 00:00:03 |
|   1 |  NESTED LOOPS          |                        | 19027 |   334K|   455   (3)| 00:00:03 |
|   2 |   VIEW                 | VW_NSO_1               | 19027 |   241K|   449   (2)| 00:00:03 |
|   3 |    HASH UNIQUE         |                        | 19027 |   798K|            |          |
|*  4 |     HASH JOIN          |                        | 19027 |   798K|   449   (2)| 00:00:03 |
|*  5 |      HASH JOIN         |                        |   464 | 13456 |    31   (4)| 00:00:01 |
|*  6 |       TABLE ACCESS FULL| POLICY_RECORD_REVISION |   464 |  9280 |    21   (0)| 00:00:01 |
|*  7 |       TABLE ACCESS FULL| POLICY_RECORD          |  4067 | 36603 |     9   (0)| 00:00:01 |
|*  8 |      INDEX RANGE SCAN  | SBLI_ATTRIBUTE_CDX     |   166K|  2282K|   416   (1)| 00:00:03 |
|*  9 |   INDEX UNIQUE SCAN    | BOOKING_LINE_PK        |     1 |     5 |     1   (0)| 00:00:01 |

此查询执行速度非常快，并立即返回行。但是，如果我添加如下OR 条件，查询将挂起（或需要很长时间）：

    SELECT booking_line_id
FROM booking_line
WHERE 1=0 or   (booking_line_id in
  (SELECT sbli.booking_line_id
   FROM search_booking_line_index sbli,
     policy_record pr,
     policy_record_revision prr
   WHERE sbli.attribute_name = 2209
   AND sbli.policy_record_id = pr.policy_record_id
   AND pr.latest_revision_id = prr.policy_record_revision_id
   AND LOWER(prr.broker_reference) LIKE '%123%'));

执行计划：

|   0 | SELECT STATEMENT               |                           |   166K|   811K|   484   (2)| 00:00:03 |
|*  1 |  FILTER                        |                           |       |       |            |          |
|   2 |   INDEX FAST FULL SCAN         | BOOKING_LINE_PK           |   166K|   811K|    66   (5)| 00:00:01 |
|   3 |   NESTED LOOPS                 |                           |     1 |    43 |   419   (1)| 00:00:03 |
|   4 |    NESTED LOOPS                |                           |     1 |    23 |   418   (1)| 00:00:03 |
|*  5 |     INDEX RANGE SCAN           | SBLI_ATTRIBUTE_CDX        |     1 |    14 |   417   (1)| 00:00:03 |
|*  6 |     TABLE ACCESS BY INDEX ROWID| POLICY_RECORD             |     1 |     9 |     1   (0)| 00:00:01 |
|*  7 |      INDEX UNIQUE SCAN         | POLICY_RECORD_PK          |     1 |       |     1   (0)| 00:00:01 |
|*  8 |    TABLE ACCESS BY INDEX ROWID | POLICY_RECORD_REVISION    |     1 |    20 |     1   (0)| 00:00:01 |
|*  9 |     INDEX UNIQUE SCAN          | POLICY_RECORD_REVISION_PK |     1 |       |     1   (0)| 00:00:01 |

预计这应该与第一个查询所用的时间相同。但令人惊讶的是，它没有。

任何人都可以帮我解释同样的原因吗？

【问题讨论】：

有一些关于它的信息here（最佳答案：“或者在 SQL Server 上是出了名的慢。”）
@keyser5053：这是否同样适用于 Oracle 和 MSSQL？
我听说这是一个 SQL 问题，但不要相信我的话......
您在 Table1 或 Table2 上有索引吗？检查执行计划，看看有什么不同，也许优化器决定不使用某些索引...
我添加了确切的查询和执行计划。请检查。索引到位

标签： sql oracle

【解决方案1】：

至少在 11gR2 中，计划和执行是完全相同的。这是我的设置：

CREATE TABLE table1 AS SELECT * FROM dba_objects WHERE object_id IS NOT NULL;
CREATE TABLE table2 AS SELECT * FROM dba_objects WHERE object_id IS NOT NULL 
                                                   AND object_type = 'VIEW';

ALTER TABLE table1 ADD CONSTRAINT table1_pk PRIMARY KEY (object_id);
ALTER TABLE table2 ADD CONSTRAINT table2_pk PRIMARY KEY (object_id);

第一个查询的执行计划：

SQL> EXPLAIN PLAN FOR SELECT * FROM TABLE1
  2                    WHERE OBJECT_ID IN (SELECT OBJECT_ID FROM TABLE2);

SQL> SELECT * FROM TABLE(dbms_xplan.display);

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 2776518249
--------------------------------------------------------------------------------
| Id  | Operation                    | Name      | Rows  | Bytes | Cost (%CPU)|
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |           | 31523 |  6772K|   584   (1)|
|   1 |  MERGE JOIN                  |           | 31523 |  6772K|   584   (1)|
|   2 |   TABLE ACCESS BY INDEX ROWID| TABLE1    |   396K|    78M|   575   (1)|
|   3 |    INDEX FULL SCAN           | TABLE1_PK |   396K|       |    77   (0)|
|*  4 |   SORT JOIN                  |           | 31523 |   400K|    10  (30)|
|   5 |    INDEX FULL SCAN           | TABLE2_PK | 31523 |   400K|     7   (0)|
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   4 - access("OBJECT_ID"="OBJECT_ID")
       filter("OBJECT_ID"="OBJECT_ID")

SQL>

对于第二个查询：

SQL> EXPLAIN PLAN FOR SELECT * FROM TABLE1
  2             WHERE 1 = 0 OR OBJECT_ID IN (SELECT OBJECT_ID FROM TABLE2); 

SQL> SELECT * FROM TABLE(dbms_xplan.display);

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 2776518249
--------------------------------------------------------------------------------
| Id  | Operation                    | Name      | Rows  | Bytes | Cost (%CPU)|
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |           | 31523 |  6772K|   584   (1)|
|   1 |  MERGE JOIN                  |           | 31523 |  6772K|   584   (1)|
|   2 |   TABLE ACCESS BY INDEX ROWID| TABLE1    |   396K|    78M|   575   (1)|
|   3 |    INDEX FULL SCAN           | TABLE1_PK |   396K|       |    77   (0)|
|*  4 |   SORT JOIN                  |           | 31523 |   400K|    10  (30)|
|   5 |    INDEX FULL SCAN           | TABLE2_PK | 31523 |   400K|     7   (0)|
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   4 - access("OBJECT_ID"="OBJECT_ID")
       filter("OBJECT_ID"="OBJECT_ID")

【讨论】：

我们使用的是Oracle10g，执行计划不同。
更新了主要描述中的执行计划

【解决方案2】：

似乎是因为你让服务器改变了执行计划。第一个查询是使用内部连接执行的，这就是它如此之快的原因。但在第二个过程中，必须检查第一个条件，然后在需要时进行选择。您可以像这样更改查询：

select ... 
 from t
 left join t2
 where 1=0 or t2.id is not null

【讨论】：