SQL Server的执行计划及SQL查询优化实例分析与总结

SQL Server的执行计划及SQL查询优化是本文我们主要要介绍的内容，谈到优化就必然要涉及索引，就像要讲锁必然要说事务一样，所以你需要了解一下索引，今天来探索下SQL Server的执行计划，来让大家知道如何查看SQL Server的优化机制，以此来优化SQL查询。

--DROP TABLE T_UserInfo----------------------------------------------------  
--建测试表  
CREATE TABLE T_UserInfo  
(  
Userid varchar(20), UserName varchar(20),  
RegTime datetime, Tel varchar(20),  
)

–插入测试数据

DECLARE @I INT  
DECLARE @ENDID INT  
SELECT @I = 1 
SELECT @ENDID = 100 --在此处更改要插入的数据，重新插入之前要删掉所有数据  
WHILE @I <= @ENDID  
BEGIN  
INSERT INTO T_UserInfo  
SELECT 'ABCDE'+CAST(@I AS VARCHAR(20))+'EF','李'+CAST(@I AS VARCHAR(20)),  
GETDATE(),'876543'+CAST(@I AS VARCHAR(20))  
SELECT @I = @I + 1  
END

--建聚集索引  
CREATE CLUSTERED INDEX INDEX_Userid ON T_UserInfo (Userid)  
--建非聚集索引  
CREATE NONCLUSTERED INDEX INDEX_Userid ON T_UserInfo (Userid)  
--删除索引  
DROP INDEX T_UserInfo.INDEX_Userid  
--显示有关由Transact-SQL 语句生成的磁盘活动量的信息  
SET STATISTICS IO ON  
--关闭有关由Transact-SQL 语句生成的磁盘活动量的信息  
SET STATISTICS IO OFF  
--显示[返回有关语句执行情况的详细信息，并估计语句对资源的需求]  
SET SHOWPLAN_ALL ON  
--关闭[返回有关语句执行情况的详细信息，并估计语句对资源的需求]  
SET SHOWPLAN_ALL OFF

请记住：SET STATISTICS IO 和 SET SHOWPLAN_ALL 是互斥的。

OK，现在开始：

首先，我们插入100条数据，然后我写了一个查询语句：SELECT * FROM T_UserInfo WHERE USERID=’ABCDE6EF’，这就是SQL Server的执行计划。

表扫描：扫描表中的行，然后我们来看该语句对IO的读写，执行:SET STATISTICS IO ON，此时再执行该SQL:SELECT * FROM T_UserInfo WHERE USERID=’ABCDE6EF’。

切换到消失栏显示如下：表’T_UserInfo’。扫描计数1，逻辑读1 次，物理读0 次，预读0 次。

四个值分别为：执行的扫描次数;从数据缓存读取的页数;从磁盘读取的页数;为进行查询而放入缓存的页数。

注意：如果对于一个SQL查询有多种写法，那么这四个值中的逻辑读(logical reads)决定了哪个是***化的。

接下来我们为其建一个聚集索引，执行CREATE CLUSTERED INDEX INDEX_Userid ON T_UserInfo (Userid)，然后再执行SELECT * FROM T_UserInfo WHERE USERID=’ABCDE6EF’

切换到消息栏如下显示：

表’T_UserInfo’。扫描计数1，逻辑读2 次，物理读0 次，预读0 次。

此时逻辑读由原来的1变成2，说明我们又加了一个索引页，现在我们查询时，逻辑读就是要读两页(1索引页+1数据页)，此时的效率还不如不建索引。

聚集索引查找：扫描聚集索引中特定范围的行，说明，此时用了索引。OK,到这里你应该已经知道初步知道MSSQL查询计划和如何查看对IO的读取消耗了吧！

接下来我们继续：

现在我再把测试数据改变成1000条，再执行SET STATISTICS IO ON,再执行，SELECT * FROM T_UserInfo WHERE USERID=’ABCDE6EF’

在不加聚集索引的情况下：表’T_UserInfo’。扫描计数1，逻辑读7 次，物理读0 次，预读0 次。

在加聚集索引的情况下：CREATE CLUSTERED INDEX INDEX_Userid ON T_UserInfo (Userid)，表’T_UserInfo’。扫描计数1，逻辑读2 次，物理读0 次，预读0 次。(其实也就是说此时是读了一个索引页，一个数据页)如此，在数据量稍大时，索引的查询优势就显示出来了。

总结：

当你构建SQL语句时，按Ctrl+L就可以看到语句是如何执行，是用索引扫描还是表扫描？

通过SET STATISTICS IO ON 来查看逻辑读，完成同一功能的不同SQL语句，逻辑读越小查询速度越快(当然不要找那个只有几百条记录的例子来反我)。

我们再继续深入：

OK，现在我们再来看一次，我们换个SQL语句，来看下MSSQL如何来执行的此SQL呢？

现在去掉索引：DROP INDEX T_UserInfo.INDEX_Userid，现在打开[显示语句执行情况的详细信息]：SET SHOWPLAN_ALL ON，然后再执行：SELECT * FROM T_UserInfo WHERE USERID LIKE ‘ABCDE8%’

看结果栏：结果中有些具体参数，比如IO的消耗，CPU的消耗。

在这里我们只看StmtText:SELECT * FROM T_UserInfo WHERE USERID LIKE ‘ABCDE8%’|–Table Scan(OBJECT:([student].[dbo].[T_UserInfo]), WHERE:(like([T_UserInfo].[Userid], ‘ABCDE8%’, NULL)))

我再加上索引：

先关闭：SET SHOWPLAN_ALL OFF

再执行：CREATE CLUSTERED INDEX INDEX_Userid ON T_UserInfo (Userid)

再开启：SET SHOWPLAN_ALL ON

再执行：SELECT * FROM T_UserInfo WHERE USERID LIKE ‘ABCDE8%’

查看StmtText:SELECT * FROM T_UserInfo WHERE USERID LIKE ‘ABCDE8%’|–Clustered Index Seek(OBJECT:([student].[dbo].[T_UserInfo].[INDEX_Userid]), SEEK:([T_UserInfo].[Userid] >= ‘ABCDE8’ AND [T_UserInfo].[Userid] < ‘ABCDE9’), WHERE:(like([T_UserInfo].[Userid], ‘ABCDE8%’, NULL)) ORDERED FORWARD)

在有索引的情况下，我们再写一个SQL：

SET SHOWPLAN_ALL ON  
SELECT * FROM T_UserInfo WHERE LEFT(USERID,4)='ABCDE8%'

查看StmtText:SELECT * FROM T_UserInfo WHERE LEFT(USERID,4)=’ABCDE8%’|–Clustered Index Scan(OBJECT:([student].[dbo].[T_UserInfo].[INDEX_Userid]), WHERE:(substring([T_UserInfo].[Userid], 1, 4)=’ABCDE8%’))

我们再分别看一下三种情况下对IO的操作

分别如下：

***种情况：表’T_UserInfo’。扫描计数1，逻辑读7 次，物理读0 次，预读0 次。

第二种情况：表’T_UserInfo’。扫描计数1，逻辑读3 次，物理读0 次，预读0 次。

第三种情况：表’T_UserInfo’。扫描计数1，逻辑读8 次，物理读0 次，预读0 次。

这说明:

***次是表扫描，扫了7页，也就是全表扫描

第二次是索引扫描，扫了1页索引，2页数据页

第三次是索引扫描+表扫描，扫了1页索引，7页数据页。

[图形界面也有对CPU和IO的消耗，也可以看出来哪个***!]

通过比较，很容易的看出：第二种第三种写法在都有索引的情况下，like有效的使用索引，而left则不能，这样一个最简单的优化的例子就出来了。

在上面的例子中，用的是聚集索引扫描，字段是字母加数字，大家可以试试看纯数字的、字母的、汉字的等等，了解下SQL Server会如何改变SQL语句来利用索引。然后再试试非聚集索引是什么情况？用不用索引和什么有关？子查询MSSQL是如何执行？IN用不用索引，LIKE用不用索引？函数用不用索引？OR、AND、UNION？子查询呢？在这里我不一一去试给大家看了，只要知道了如何去看MSSQL的执行计划（图形和文本)，很多事情就很明朗了。

总结：

实现同一查询功能的SQL写法可能会有多种，如果判断哪种***化，如果仅仅是从时间上来测，会受很多外界因素的影响，而我们明白了MSSQL如何去执行，通过IO逻辑读、通过查看图示的查询计划、通过其优化后而执行的SQL语句，才是优化SQL的真正途径。

另外提醒下：数据量的多少有时会影响MSSQL对同一种查询写法语句的执行计划，这一点在非聚集索引上特别明显，还有就是在多CPU与单CPU下，在多用户并发情况下，同一写法的查询语句执行计划会有所不同，这个就需要大家有机会去试验。

关于SQL Server执行计划及SQL查询优化的实例分析就介绍到这里了，希望本次的介绍能够对您有所收获！

【编辑推荐】