SQL Server 查询性能优化——索引与SARG（四）
上接SQL Server 查询性能优化——索引与SARG（三）说明：下文中所说的创建索引都是SQL Server 查询性能优化——索引与SARG（一）中开头部分所说明的索引列表中的索引。
例：下面表格中说的索引1（聚集索引）和索引5（非聚集索引）
4： 小心使用OR操作符
如上文SQL Server 查询性能优化——索引与SARG（三）中的例子中WBK_PDE_LIST_ORG_HISTROY表创建了索引2，即在 字段建立索引，通过该索引．就可以从大量记录中．快速找出符合记录的记录(如上文中的“2请不要进行负向查询”中表格中的序号2，逻辑读取43次，执行成本0.121935)，再在少量的数据过滤COP_G_NO='60207106'的记录，因此可以发挥索引的功能。但若使用的是OR 操作，则需要所有字段都有索引可用，查询语句改成如下：
SELECT*FROM where qty_1=312 or COP_G_NO='60207106'
而当COP_G_NO字段没有适用索引时，直接扫描整个数据表。
序号
逻辑读
执行成本
查询语句
SELECT ,,,,,
,, FROM
where qty_1=312 or COP_G_NO='60207106'
索引2
1
表'WBK_PDE_LIST_ORG_HISTROY'。扫描计数1，逻辑读取1306 次，物理读取0 次，预读0 次，lob 逻辑读取0 次，lob 物理读取0 次，lob 预读0 次。
1306
1.03687
索引2,3
2
表'WBK_PDE_LIST_ORG_HISTROY'。扫描计数2，逻辑读取101 次，物理读取0 次，预读0 次，lob 逻辑读取0 次，lob 物理读取0 次，lob 预读0 次。
101
0.245731
索引4，5
3
表'WBK_PDE_LIST_ORG_HISTROY'。扫描计数2，逻辑读取6 次，物理读取0 次，预读0 次，lob 逻辑读取0 次，lob 物理读取0 次，lob 预读0 次。
6
0.0125617
小结：
序号
所创建的索引
逻辑读
查询记录数量
执行成本
1
索引2
1306
90
1.03687
2
索引2,3
101
92
0.245731
3
索引4，5
6
92
0.0125617
从小结中所列的表格中，可以看出由于索引4，索引5使用了include关键字，在创建索引时把查询语句中需要中的字段添加到了非聚集索引的叶级，从而在进行查询时只需要访问到索引的叶级就可以，不需要通过RID操作去访问数据页中的数据，所以提高了查询速度。
就是说查询优化器可以在索引中找到所有列值；不访问表或聚集索引数据，从而减少磁盘 I/O 操作。但这样做的坏处是索引需要额外的磁盘存储空间。是优是劣，按实际情况进行调整。
例外情况：
使用OR操作符时，如果多个条件中有一个条件没有合适的索引，则其他条件都有索引也是没有用处的，只有整个数据表进行扫描或进行聚集索引扫描，以确定全部的数据是否有符合的记录。
即使多个条件都有索引，所需要的查询结果数量过多，SQL SERVER查询优化程序将自动采用全表扫描或聚集索引扫描，以确定全部的数据是否有符合的记录。
如下例：
创建非聚集索引4，5，没有索引1。
执行以下代码
SELECT ,,,,,,,
FROM where qty_1=2 or COP_G_NO='60207106'
表'WBK_PDE_LIST_ORG_HISTROY'。扫描计数1，逻辑读取1306 次，物理读取0 次，预读0 次，lob 逻辑读取0 次，lob 物理读取0 次，lob 预读0 次。
总结：
不要认为只要有负向查询出现在查询条件WHERE子句中就一定认为索引就没有效用，在WHERE子句中使用非SARG并不一定导致全表扫描或是聚集索引扫描。SQL SERVER可以在某些非SARG状况中使用索引，以及查询中虽然包含了部分非SARG但仍可以对此查询中的SARG部分使用索引。
也不要认为在查询语句中的查询条件WHERE子句中使用SARG就一定会使用到相应的索引，而不会进行全表扫描或聚集索引扫描。SQL SERVER查询优化程序会根据SARG使用情况所获取的查询结果的记录数量是否过多，而决定是使用相应的索引，还是使用全表扫描或是聚集索引扫描。当然，无论情况如何，在进行性能调校时，最先也是最直接的改变就是把非SARG改成SARG。因为把非SARG改成SARG最坏的情况就是全表扫描或是聚集索引扫描，查询结果的记录数量比较少，会高效利用相应索引，快速查出结果。
页:
[1]