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,并没有确定的孰优孰劣,使用时要进行测试才能确定。“ 。
SQL SERVER中关于OR会导致索引扫描或全表扫描的浅析相关推荐
- SQL SERVER中什么情况会导致索引查找变成索引扫描
原文:SQL SERVER中什么情况会导致索引查找变成索引扫描 SQL Server 中什么情况会导致其执行计划从索引查找(Index Seek)变成索引扫描(Index Scan)呢? 下面从几个方 ...
- SQL Server中TOP子句可能导致的问题以及解决办法
SQL Server中TOP子句可能导致的问题以及解决办法 参考文章: (1)SQL Server中TOP子句可能导致的问题以及解决办法 (2)https://www.cnblogs.com/firs ...
- cte公用表表达式_在SQL Server中使用CTE进行插入和更新(公用表表达式)
cte公用表表达式 In CTEs in SQL Server; Querying Common Table Expressions the first article of this series, ...
- SQL Server临界点游戏——为什么非聚集索引被忽略!
当我们进行SQL Server问题处理的时候,有时候会发现一个很有意思的现象:SQL Server完全忽略现有定义好的非聚集索引,直接使用表扫描来获取数据.我们来看看下面的表和索引定义: 1 CREA ...
- predicate 列存储索引扫描_在SQL SERVER中导致索引查找变成索引扫描的问题分析
SQL Server 中什么情况会导致其执行计划从索引查找(Index Seek)变成索引扫描(Index Scan)呢? 下面从几个方面结合上下文具体场景做了下测试.总结.归纳. 1:隐式转换会导致 ...
- 如何在SQL Server中索引外键列
Before going through the main concern of this article, indexing the foreign key columns, let's take ...
- SQL Server中一些常见的性能问题
SQL Server中一些常见的性能问题: 1.在对查询进行优化时,应当尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引. 2.我们应当尽量避免使用 left jo ...
- SQL Server中count(*), count(col), count(1)的对比
SQL Server中count(*), count(col), count(1)的对比 原文:SQL Server中count(*), count(col), count(1)的对比 让我们先看一下 ...
- SQL Server中的锁的简单学习
原文:SQL Server中的锁的简单学习 简介 在SQL Server中,每一个查询都会找到最短路径实现自己的目标.如果数据库只接受一个连接一次只执行一个查询.那么查询当然是要多快好省的完成工作.但 ...
最新文章
- 根据输入的日期计算你活了多少天(新手)
- OpenGL帧缓存对象(FBO:Frame Buffer Object)(转载)
- CentOS7修改默认运行级别
- 浅谈malloc,calloc,realloc函数之间的区别
- hibernate.jdbc.fetch_size 和 hibernate.jdbc.batch_size
- Java EE 8的前5个新功能
- python二维列表排序_使用Python按顺时针方向排序二维坐标列表?
- MySql Delimiter
- codeforces Gargari and Permutations(DAG+BFS)
- 用这开源小书学 Docker,香!
- html input 文本框的一些操作(限制输入...)
- cactus java_Cactus入门
- Flutter高级第6篇:事件广播 、事件监听
- 国网B接口调阅实时视频(INVITE)接口描述和消息示例
- 计算机硬盘序列号有什么意义,硬盘序列号会/为什么会改变
- 我在CSDN的2021--一次没有专栏的写在尾声
- 《动手学深度学习》(七) -- 边界框和锚框
- shell脚本编写创建多层目录,判断目录是否存在,存在则删除并且给文件赋予权限
- 阿里云装mysql选择版本_mysql学习之-三种安装方式与版本介绍
- 【jprofiler】jprofiler安装使用教程
热门文章
- 正整数的唯一分解定理 c语言,SSOJ2662正整数的唯一分解定理
- c# list集合根据某个字段去重_java8 List 根据对象某个字段或多个字段去重、筛选、List转Map、排序、分组、统计计数等等...
- ping端口怎么ping_英雄联盟手游ping信号怎么发送 ping信号发送方法介绍_游戏攻略...
- mysql优化难 选db2_DB2数据库优化的几条策略_MySQL
- java平方和和立方和3_平方和与立方和
- 使用Maven的jaxws-maven-plugin插件,将wsdl生成java
- 华为的JAVA面试题及答案(部分)
- 吴军《谷歌面试题:倒置英文句子》
- ES6学习笔记01:Symbol数据类型
- 现在时的条件句_57