SQL SERVER中关于OR会致使索引扫描或全表扫描的浅析

在SQL SERVER的查询语句中使用OR是否会致使不走索引查找（Index Seek）或索引失效（堆表走全表扫描 （Table Scan）、汇集索引表走汇集索引扫描（Clustered Index Scan））呢？是否全部状况都是如此？又该如何优化呢？ 下面咱们经过一些简单的例子来分析理解这些现象。下面的实验环境为SQL SERVER 2008，若是在不一样版本有所区别，欢迎指正。

 

堆表单索引

首先咱们构建咱们测试须要实验环境，具体状况以下所示：

DROP TABLE TEST

CREATE TABLE TEST (OBJECT_ID  INT, NAME VARCHAR(32));

CREATE INDEX PK_TEST ON TEST(OBJECT_ID)

DECLARE @Index INT =0;

WHILE @Index < 500000

BEGIN

    INSERT INTO TEST

    SELECT @Index, 'kerry'+CAST(@Index AS VARCHAR(6));

    SET @Index = @Index +1;

END

UPDATE STATISTICS TEST WITH FULLSCAN

 

场景1：以下所示，并非全部的OR条件都会致使SQL走全表扫描。具体状况具体分析，不要套用教条。

SELECT * FROM TEST WHERE (OBJECT_ID =5 OR OBJECT_ID = 105)

 

场景2：加了条件1=1后，执行计划从索引查找（Index Seek）变为全表扫描（Table Scan），为何会如此呢？我的理解为优化器将OR运算拆分为两个子集处理，因为一些缘由，1=1这个条件致使优化器认定须要全表扫描才能完成1=1条件子集的计算处理（为了理解这个，煞费苦心，鉴于理论薄弱，若有错误或不足，敬请指出）。因此优化器在权衡代价后生成的执行计划最终选择了全表扫描（Table Scan）

SELECT * FROM TEST WHERE (1=1 OR OBJECT_ID =105);

 

场景3: 下面场景比较好理解，由于下面须要从500000条记录中取出499700条记录，而全表扫描（Table Scan）确定是最优的选择，代价（Cost）最低。

SELECT * FROM TEST WHERE (OBJECT_ID >300 OR OBJECT_ID =105); 

 

场景4：这种场景跟场景2的状况本质是同样的。因此在此略过。其实相似这种写法也是实际状况中最常出现的状况，还在迷糊的同窗，赶忙抛弃这种写法吧

DECLARE @OBJECT_ID INT =150;

SELECT * FROM TEST WHERE (@OBJECT_ID IS NULL OR OBJECT_ID =@OBJECT_ID);

 

汇集索引表单索引

在汇集索引表中，咱们也依葫芦画瓢，准备实验测试的数据环境。

DROP TABLE TEST

CREATE TABLE TEST (OBJECT_ID  INT, NAME VARCHAR(32));

CREATE CLUSTERED INDEX PK_TEST ON TEST(OBJECT_ID)

DECLARE @Index INT =0;

WHILE @Index < 500000

BEGIN

    INSERT INTO TEST

    SELECT @Index, 'kerry'+CAST(@Index AS VARCHAR(6));

    SET @Index = @Index +1;

END

UPDATE STATISTICS TEST WITH FULLSCAN

 

场景1 ：索引查找（Index Seek）

 

SELECT * FROM TEST WHERE (OBJECT_ID =5 OR OBJECT_ID = 105)

 

场景2：汇集索引扫描（Clustered Index Scan）

 

场景3：彷佛与堆表有所不一样。汇集索引表竟然仍是走汇集索引查找。

 

场景4：OR致使汇集索引扫描

 

若是堆表或汇集索引表上创建有联合索引,状况也大体如此，在此不作过多案例讲解。下面仅仅讲述一两个案例场景。

DROP TABLE test1; 

CREATE TABLE test1 

  ( 

     a INT, 

     b INT, 

     c INT, 

     d INT, 

     e INT 

  ) 

DECLARE @Index INT =0; 

WHILE @Index < 10000 

  BEGIN 

      INSERT INTO test1 

      SELECT @Index, 

             @Index, 

             @Index, 

             @Index, 

             @Index 

      SET @Index = @Index + 1; 

  END 

CREATE INDEX idx_test_n1 

  ON test1(a, b, c, d) 

UPDATE STATISTICS test1 WITH fullscan; 

SELECT * FROM TEST1 WHERE A=12 OR B> 500 OR C >100000

 

由于结果集是几个条件的并集，最多只能在查找A=12的数据时用索引，其它几个条件都须要表扫描，那优化器就会选择直接走一遍表扫描，以最低的代价COST完成，因此索引就失效了。

 

那么如何优化查询语句含有的OR的SQL语句呢？方法无外乎有三种：

1：经过索引覆盖，使包含OR的SQL走索引查找（Index Seek）。可是这个只能知足部分场景，并不能解决全部这类SQL。这个Solution具备必定的局限性。

SELECT * FROM TEST1 WHERE A=12 OR B=500

若是咱们经过索引覆盖，在字段B上面也创建索引，那么下面OR查询也会走索引查找。

CREATE INDEX IDX_TEST1_B ON TEST1(B);

SELECT * FROM TEST1 WHERE A=12 OR B=500 

 

2：使用IN替换OR。 可是这个Solution也有不少局限性。在此不作过多阐述。

 

3：通常将OR的字句分解成多个查询，而且经过UNION ALL 或UNION链接起来。在联合索引或有索引覆盖的场景下。大部分状况下，UNION ALL的效率更高。可是并非全部的UNION ALL都会比OR的SQL的代价（COST），特殊的状况或特殊的数据分布也会出现UNION ALL比OR代价要高的状况。例如，上面特殊的要求，从全表中取两条记录，以下所示

SELECT * FROM TEST1 WHERE A=12

UNION ALL

SELECT * FROM TEST1 WHERE B=500 

 

UNON ALL语句的代价（Cost）要高与OR是由于它作了两次索引查找（Index Seek），而OR语句只作一次索引查找（Index Seek）就完成了。开销明显小一些，可是实际状况这类特殊状况比较少，实际状况的取数条件、数据都比这个简单案例要复杂得多。因此在大部分状况下，拆分为UNION ALL语句的效率要高于OR语句

另一个案例，就是最上面实验的堆表TEST， 在字段OBJECT_ID上建有索引

SELECT * FROM TEST WHERE (OBJECT_ID >300 OR OBJECT_ID =105);

SELECT * FROM TEST WHERE OBJECT_ID >300

UNION ALL

SELECT * FROM TEST WHERE OBJECT_ID =105;

能够从下面看出二者开销不一样的地方在于IO方面，二者开销之因此有区别，是由于第二个SQL多了一次扫描（索引查找）

 

总结：

    在实际开发环境中，OR这种写法确实会带来不少不肯定性，尽可能使用UNION 或IN替换OR。咱们须要遵循一些规则，可是也不能认为它就是一成不变的，永为真理。具体场景、具体环境具体分析。要知其然知其因此然。在微软亚太区数据库技术支持组的官方博客中就有一个案例SQL Server性能问题案例解析 （3）也是OR引发的性能案例。 博客中有个观点，我以为挺赞的：”须要注意的是，对于OR或UNION，并无肯定的孰优孰劣，使用时要进行测试才能肯定。“ 。