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中不做运算
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）进行聚集索引查找。速度非常快。
