在SQL SERVER中导致索引查找变成索引扫描的问题分析

SQL Server 中什么情况会导致其执行计划从索引查找(Index Seek)变成索引扫描(Index Scan)呢? 下面从几个方面结合上下文具体场景做了下测试、总结、归纳。

1:隐式转换会导致执行计划从索引查找(Index Seek)变为索引扫描(Index Scan)

Implicit Conversion will cause index scan instead of index seek. While implicit conversions occur in SQL Server to allow data evaluations against different data types, they can introduce performance problems for specific data type conversions that result in an index scan occurring during the execution.  Good design practices and code reviews can easily prevent implicit conversion issues from ever occurring in your design or workload.

如下示例,AdventureWorks2014数据库的HumanResources.Employee表,由于NationalIDNumber字段类型为NVARCHAR,下面SQL发生了隐式转换,导致其走索引扫描(Index Scan)

SELECT NationalIDNumber, LoginID
FROM HumanResources.Employee
WHERE NationalIDNumber = 112457891 

我们可以通过两种方式避免SQL做隐式转换:

1:确保比较的两者具有相同的数据类型。

2:使用强制转换(explicit conversion)方式。

我们通过确保比较的两者数据类型相同后,就可以让SQL走索引查找(Index Seek),如下所示

SELECT nationalidnumber,
    loginid
FROM  humanresources.employee
WHERE nationalidnumber = N'112457891' 

注意:并不是所有的隐式转换都会导致索引查找(Index Seek)变成索引扫描(Index Scan),Implicit Conversions that cause Index Scans 博客里面介绍了那些数据类型之间的隐式转换才会导致索引扫描(Index Scan)。如下图所示,在此不做过多介绍。

避免隐式转换的一些措施与方法

1:良好的设计和代码规范(前期)

2:对发布脚本进行Rreview(中期)

3:通过脚本查询隐式转换的SQL(后期)

下面是在数据库从执行计划中搜索隐式转换的SQL语句

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
DECLARE @dbname SYSNAME
SET @dbname = QUOTENAME(DB_NAME());
WITH XMLNAMESPACES
  (DEFAULT 'http://schemas.microsoft.com/sqlserver/2004/07/showplan')
SELECT
  stmt.value('(@StatementText)[1]', 'varchar(max)'),
  t.value('(ScalarOperator/Identifier/ColumnReference/@Schema)[1]', 'varchar(128)'),
  t.value('(ScalarOperator/Identifier/ColumnReference/@Table)[1]', 'varchar(128)'),
  t.value('(ScalarOperator/Identifier/ColumnReference/@Column)[1]', 'varchar(128)'),
  ic.DATA_TYPE AS ConvertFrom,
  ic.CHARACTER_MAXIMUM_LENGTH AS ConvertFromLength,
  t.value('(@DataType)[1]', 'varchar(128)') AS ConvertTo,
  t.value('(@Length)[1]', 'int') AS ConvertToLength,
  query_plan
FROM sys.dm_exec_cached_plans AS cp
CROSS APPLY sys.dm_exec_query_plan(plan_handle) AS qp
CROSS APPLY query_plan.nodes('/ShowPlanXML/BatchSequence/Batch/Statements/StmtSimple') AS batch(stmt)
CROSS APPLY stmt.nodes('.//Convert[@Implicit="1"]') AS n(t)
JOIN INFORMATION_SCHEMA.COLUMNS AS ic
  ON QUOTENAME(ic.TABLE_SCHEMA) = t.value('(ScalarOperator/Identifier/ColumnReference/@Schema)[1]', 'varchar(128)')
  AND QUOTENAME(ic.TABLE_NAME) = t.value('(ScalarOperator/Identifier/ColumnReference/@Table)[1]', 'varchar(128)')
  AND ic.COLUMN_NAME = t.value('(ScalarOperator/Identifier/ColumnReference/@Column)[1]', 'varchar(128)')
WHERE t.exist('ScalarOperator/Identifier/ColumnReference[@Database=sql:variable("@dbname")][@Schema!="[sys]"]') = 1

2:非SARG谓词会导致执行计划从索引查找(Index Seek)变为索引扫描(Index Scan)

SARG(Searchable Arguments)又叫查询参数, 它的定义:用于限制搜索的一个操作,因为它通常是指一个特定的匹配,一个值的范围内的匹配或者两个以上条件的AND连接。不满足SARG形式的语句最典型的情况就是包括非操作符的语句,如:NOT、!=、<>;、!<;、!>;NOT EXISTS、NOT IN、NOT LIKE等,另外还有像在谓词使用函数、谓词进行运算等。

2.1:索引字段使用函数会导致索引扫描(Index Scan)

SELECT nationalidnumber,
    loginid
FROM  humanresources.employee
WHERE SUBSTRING(nationalidnumber,1,3) = '112'

2.2索引字段进行运算会导致索引扫描(Index Scan)

对索引字段字段进行运算会导致执行计划从索引查找(Index Seek)变成索引扫描(Index Scan):

SELECT * FROM Person.Person WHERE BusinessEntityID + 10 < 260

一般要尽量避免这种情况出现,如果可以的话,尽量对SQL进行逻辑转换(如下所示)。虽然这个例子看起来很简单,但是在实际中,还是见过许多这样的案例,就像很多人知道抽烟有害健康,但是就是戒不掉!很多人可能了解这个,但是在实际操作中还是一直会犯这个错误。道理就是如此!

SELECT * FROM Person.Person WHERE BusinessEntityID < 250

2.3 LIKE模糊查询回导致索引扫描(Index Scan)

Like语句是否属于SARG取决于所使用的通配符的类型, LIKE 'Condition%' 就属于SARG、LIKE '%Condition'就属于非SARG谓词操作

SELECT * FROM Person.Person WHERE LastName LIKE 'Ma%'

SELECT * FROM Person.Person WHERE LastName LIKE '%Ma%'

3:SQL查询返回数据页(Pages)达到了临界点(Tipping Point)会导致索引扫描(Index Scan)或表扫描(Table Scan)

What is the tipping point?
It's the point where the number of rows returned is "no longer selective enough". SQL Server chooses NOT to use the nonclustered index to look up the corresponding data rows and instead performs a table scan.

关于临界点(Tipping Point),我们下面先不纠结概念了,先从一个鲜活的例子开始吧:

SET NOCOUNT ON;
DROP TABLE TEST
CREATE TABLE TEST (OBJECT_ID INT, NAME VARCHAR(8));
CREATE INDEX PK_TEST ON TEST(OBJECT_ID)
DECLARE @Index INT =1;
WHILE @Index <= 10000
BEGIN
  INSERT INTO TEST
  SELECT @Index, 'kerry';
  SET @Index = @Index +1;
END
UPDATE STATISTICS TEST WITH FULLSCAN;
SELECT * FROM TEST WHERE OBJECT_ID= 1

如上所示,当我们查询OBJECT_ID=1的数据时,优化器使用索引查找(Index Seek)

上面OBJECT_ID=1的数据只有一条,如果OBJECT_ID=1的数据达到全表总数据量的20%会怎么样? 我们可以手工更新2001条数据。此时SQL的执行计划变成全表扫描(Table Scan)了。

UPDATE TEST SET OBJECT_ID =1 WHERE OBJECT_ID<=2000;
UPDATE STATISTICS TEST WITH FULLSCAN;
SELECT * FROM TEST WHERE OBJECT_ID= 1

临界点决定了SQL Server是使用书签查找还是全表/索引扫描。这也意味着临界点只与非覆盖、非聚集索引有关(重点)。

Why is the tipping point interesting?
It shows that narrow (non-covering) nonclustered indexes have fewer uses than often expected (just because a query has a column in the WHERE clause doesn't mean that SQL Server's going to use that index)
It happens at a point that's typically MUCH earlier than expected… and, in fact, sometimes this is a VERY bad thing!
Only nonclustered indexes that do not cover a query have a tipping point. Covering indexes don't have this same issue (which further proves why they're so important for performance tuning)
You might find larger tables/queries performing table scans when in fact, it might be better to use a nonclustered index. How do you know, how do you test, how do you hint and/or force… and, is that a good thing?

4:统计信息缺失或不正确会导致索引扫描(Index Scan)

统计信息缺失或不正确,很容易导致索引查找(Index Seek)变成索引扫描(Index Scan)。 这个倒是很容易理解,但是构造这样的案例比较难,一时没有想到,在此略过。

5:谓词不是联合索引的第一列会导致索引扫描(Index Scan)

SELECT * INTO Sales.SalesOrderDetail_Tmp FROM Sales.SalesOrderDetail;
CREATE INDEX PK_SalesOrderDetail_Tmp ON Sales.SalesOrderDetail_Tmp(SalesOrderID, SalesOrderDetailID);
UPDATE STATISTICS  Sales.SalesOrderDetail_Tmp WITH FULLSCAN;

下面这个SQL语句得到的结果是一致的,但是第二个SQL语句由于谓词不是联合索引第一列,导致索引扫描

SELECT * FROM Sales.SalesOrderDetail_Tmp
WHERE SalesOrderID=43659 AND SalesOrderDetailID<10

SELECT * FROM Sales.SalesOrderDetail_Tmp WHERE SalesOrderDetailID<10

(0)

相关推荐

  • mssql 建立索引第1/2页

    表的索引与附在一本书后面的索引非常相似.它可以极大地提高查询的速度.对一个较大的表来说,通过加索引,一个通常要花费几个小时来完成的查询只要几分钟就可以完成.因此没有理由对需要频繁查询的表增加索引. 注意: 当你的内存容量或硬盘空间不足时,也许你不想给一个表增加索引.对于包含索引的数据库,SQL Sever需要一个可观的额外空间.例如,要建立一个聚簇索引,需要大约1.2倍于数据大小的空间.要看一看一个表的索引在数据库中所占的空间大小,你可以使用系统存储过程sp_spaceused,对象名指定为被索

  • SQL2005CLR函数扩展 - 关于山寨索引

    本文只是一个山寨试验品,思路仅供参考. --------------------------------------------------------------------------------原理介绍:索引建立 目录结构划分方案也只是很简易的实现了一下,通过unicode把任意连续的两个字符(中文或英文)分为4个字节来做四层目录,把索引的内容对应的主关键字(主要为了使用sql索引和唯一性)作为文件名,两个字符在索引内容中的位置作为文件后缀来存储.文件本身为0字节,不保存任何信息. 比如一

  • 详解sqlserver查询表索引

    SELECT   索引名称=a.name ,表名=c.name ,索引字段名=d.name ,索引字段位置=d.colid FROM sysindexes a JOIN sysindexkeys b ON a.id=b.id AND a.indid=b.indid JOIN sysobjects c ON b.id=c.id JOIN syscolumns d ON b.id=d.id AND b.colid=d.colid WHERE a.indid NOT IN(0,255) -- and

  • 理解Sql Server中的聚集索引

    说到聚集索引,我想每个码农都明白,但是也有很多像我这样的猥程序员,只能用死记硬背来解决这个问题,什么表中只能建一个聚集索引,然后又扯到了目录查找来帮助读者记忆....问题就在这里,我们不是学文科,,,不需要去死记硬背,,,我们需要的就是能看到在眼里面的真实东西.....我们都喜欢聚集索引,因为它能够把无序的堆表记录变成有序,还玩起了B树...这样就把复杂度从N降低到了LogMN... 这样的话逻辑读,物理读就下来了.  一:现象 1:无索引的情况 还是老规矩,看个例子感受下,首先我有一个Prod

  • 关于重新组织和重新生成索引sp_RefreshIndex的介绍

    开始: -------------------------------------------------------------------------------- 在上周,客户反映一个系统问题,当处理大量数据的时候,出现网络超时.后来,我们跟踪测试,发现是由于索引碎片多而引起的网络超时. 解决方法,自然是重新组织和重新生成索引.在这里,我写了一个存储过程sp_RefreshIndex来实现. 存储过程sp_RefreshIndex: 复制代码 代码如下: use mastergoif ob

  • SQL2005重新生成索引的的存储过程 sp_rebuild_index 原创

    公司运营着的网站,流量很大,网站是交互式的,经常在过了三四个月的时候索引生成的碎片就很多,由于很大一部分页面没有生成静态,这就导致网站在打开的速度上会变慢. 以前都是手工右击索引重新生成,但是索引太多,操作起来费时费力,索引在网上找了个存储过程,自己整理了一下,执行的时候只需要选择相应的数据库,运行exec sp_rebuild_index即可,如下. USE [master] GO SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO CREATE

  • MSSQL自动重建出现碎片的索引的方法分享

    1.索引碎片的产生? 由于在表里大量的插入.修改.删除操作而使索引页分裂.如果索引有了高的碎片,有两种情况,一种情况是扫描索引需要花费很多的时间,另一种情况是在查询的时候索引根本不使用索引,都会导致性能降低. 2.碎片类型分为: 2.1 内部破碎 由于索引页里的数据插入或修改操作而发生,以数据作为稀疏矩阵的形式的分布而结束,这将导致数据页的增加,从而增加查询时间. 2.2外部破碎 由于索引/数据页的数据插入或修改而发生,以页码分离和在文件系统里不连贯的新的索引页的分配而结束,数据库服务器不能利用

  • MSSQL 大量数据时,建立索引或添加字段后保存更改提示超时的解决方法

    一般我们都喜欢用数据库管理器的UI来对数据表结构进行更改,然后自然而然地点"保存" 按钮进行保存,但数据量比较大的时候,用这招往往会出现"无法创建索引"IX_索引名". 超时时间已到.在操作完成之前超时时间已过或服务器未响应. "这种错误.一时不知所措,蜡人张的文章 复制代码 代码如下: 修改表属性后使用"索引/键"对话框为一个大型表(记录数13,239,473)创建索引,提示: - 无法创建索引"IX_TableN

  • SQL2000 全文索引完全图解

    全文检索可以对varchar,text,image型字段进行检索,但一个表最多只能建一个全文索引SQL Server 2000 引入了对存储在 image 列中的这些类型的数据执行全文检索的能力.如果没有全文索引,对字符的模糊查询只能对基表进行全表扫描(或索引扫描),执行模糊查询都需要对全表扫描或索引扫描意味着消耗大量IO.如果模糊查询经常发生,会造成数据库性能恶化.本篇为简单起见,仅在varchar型字段上图文演示非常完整的而且是高效可行的全文索引创建及维护过程.1:在企业管理器中展开要建立全

  • Sql Server中的非聚集索引详细介

    非聚集索引,这个是大家都非常熟悉的一个东西,有时候我们由于业务原因,sql写的非常复杂,需要join很多张表,然后就泪流满面了...这时候就有DBA或者资深的开发给你看这个猥琐的sql,通过执行计划一分析...或许就看出了不该有的表扫描...万恶之源...然后给你在关键的字段加上非聚集索引后...才发现提速比阿斯顿马丁还要快...那么一个问题来了,为什么非聚集索引能提速这么快...怎么做到的???是不是非常的好奇??? 这篇我们来解开神秘面纱.  一:现象 先让我们一睹非聚集索引的真容,看看到底

随机推荐