SQL Server 查询性能优化——索引与SARG（二）

当前位置:

首页 > 数据库 > T-SQL >

SQL Server 查询性能优化——索引与SARG（二）

接 SQL Server 查询性能优化——索引与SARG（一）

对于非SARG语句，SQL SERVER 必须评估每一条记录以决定它是否符合WHERE子句的条件。所以索引对于采用非SARG条件的查询通常没什么用处。而通过非SARG语句通常包含以下操作： NOT、!=、<>、!>、!< 、NOT EXISTS 、NOT IN 和NOT LIKE 等，以及上述提及的“%IS%”，其中LIKE使用方法会造成全表扫描（TARLE SCAN）或是聚集扫描而降低性能．

创建SQL Server 查询性能优化——索引与SARG（一）中开头部分创建索引中的索引1，3

				
										--例一、

										SELECT *  FROM [WBK_PDE_LIST_ORG_HISTROY] where COP_G_NO like '%79'

表'WBK_PDE_LIST_ORG_HISTROY'。扫描计数1，逻辑读取1306 次，物理读取0 次，预读0 次，lob 逻辑读取0 次，lob 物理读取0 次，lob 预读0 次。

				
										--例二、

										  SELECT *  FROM [WBK_PDE_LIST_ORG_HISTROY] with(index(idx_wbk_pde_list_cop_g_no))where COP_G_NO like '0016%'

表'WBK_PDE_LIST_ORG_HISTROY'。扫描计数1，逻辑读取925 次，物理读取0 次，预读0 次，lob 逻辑读取0 次，lob 物理读取0 次，lob 预读0 次。

				
										-----例三、

										SELECT *  FROM [WBK_PDE_LIST_ORG_HISTROY]  where COP_G_NO like '0016%'

表'WBK_PDE_LIST_ORG_HISTROY'。扫描计数1，逻辑读取1306 次，物理读取0 次，预读0 次，lob 逻辑读取0 次，lob 物理读取0 次，lob 预读0 次。

使用索引	查询语句	查询记录数量	执行成本
全表扫描	例一	916	1.03687
指定使用非聚集索引	例二	919	2.24756
使用聚集索引	例三	919	1.03687

从上表中的例一、例三中可以看出全表扫描与聚集索引扫描的执行成本是一样的，或相差不大。而例二中，使用了指定的非聚集索引，由于使用非聚集索引查找数据，会有一个RID键值查找（或称Bookup Lookup）随机操作，所以当查询的记录数量越多，则执行成本就越大。

下面来讲讲一些常见的WHERE子句用法使用不当的情景，并探讨较正确的用法：

。对WHERE子句做运算。
。负向查询。
。对WHERE子句使用函数。
。使用OR 操作。

一、不要对WHERE子句做运算
先以简单的范例来比较SARG 和非SARG ，你可以通过Managemenet studio来查看查询优化程序是否可以有效分析该语句。

1 、没有任何索引

				
										---例一：在WHERE中做运算

										SELECT  *  FROM [WBK_PDE_LIST_ORG_HISTROY] where wbook_no+G_NO='BE40494245002011844'

										---例二：在WHERE中不做运算<br data-filtered="filtered">SELECT * FROM [WBK_PDE_LIST_ORG_HISTROY] where wbook_no='BE404942450020' and g_no='11844'

1) 例一与例二查询的IO读写数

表'WBK_PDE_LIST_ORG_HISTROY'。扫描计数1，逻辑读取1306 次，物理读取0 次，预读0 次，lob 逻辑读取0 次，lob 物理读取0 次，lob 预读0 次。

2）例一与例二的查询执行计划成本

2、只创建聚集索引。

				
										ALTER TABLE [dbo].[WBK_PDE_LIST_ORG_HISTROY] ADD  CONSTRAINT [PK_WBK_PDE_LIST_ORG_HISTROY] PRIMARY KEY CLUSTERED 

										(

										[WBOOK_NO] ASC,

										[G_NO] ASC

										)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]

										GO

1) 例一与例二查询的IO读写数

表'WBK_PDE_LIST_ORG_HISTROY'。扫描计数1，逻辑读取1314 次，物理读取0 次，预读0 次，lob 逻辑读取0 次，lob 物理读取0 次，lob 预读0 次。

2）例一与例二的查询执行计划成本

3 创建SQL Server 查询性能优化——索引与SARG（一）中开头部分创建索引中的索引1（聚集索引）和索引5（非聚集索引）

1) 例一的情况同上面2.

2) 例二查询的IO读写数

表'WBK_PDE_LIST_ORG_HISTROY'。扫描计数0，逻辑读取3 次，物理读取0 次，预读0 次，lob 逻辑读取0 次，lob 物理读取0 次，lob 预读0 次。

3）例二的查询执行计划成本

从三个执行计划中，可以看到明显的差异。

因为SARG 的写法让查询优化程序可以直接对比条件常量，可以有效地利用在WHERE子句中的列名字段上建立的聚集索引或非聚集索引。而非SARG 则因为需要运算才知道数据是否符合，导致无法直接使用索引，因而采用聚集索引扫描方式、全表扫描方式、索引扫描方式。

对于第一个查询语句，由于不符合SARG格式，所以你可以看到查询优化查询并没有有效的利用索引。

第一种情况，查询优化查询对于例一与例二都使用了全表扫描方式，从上图中可以看出整个数据表有共有1306页，

而此查询语句的逻辑读是1306次，与总数据页差不多，对整个表进行了扫描。与查询计划示意图中所示一样。

第二种情况，由于没有了idx_WBK_PDE_LIST_COP_G_NO索引，只有聚集索引PK_WBK_PDE_LIST_ORG_HISTROY。从上图中可以看出PK_WBK_PDE_LIST_ORG_HISTROY的索引页共有1306页，而此查询语句的逻辑读是1314次，与总索引页差不多，也是聚集索引扫描，与查询计划示意图中所示一样。

对于第三种情况，由于符合SARG 格式，而且WHERE子句后面的条件中的字段中都建立有索引，所以你可以看到查询优化程序会有效地利用先前建立的聚集索引（索引1）进行聚集索引查找。速度非常快。

出处：https://www.cnblogs.com/chillsrc/archive/2012/11/08/2756141.html

栏目列表