共计 4509 个字符，预计需要花费 12 分钟才能阅读完成。
SqlServer 执行计划及 Sql 查询优化的示例分析，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。
谈到优化就必然要涉及索引，就像要讲锁必然要说事务一样，所以你需要了解一下索引，仅仅是索引，就能讲半天了，所以索引我就不说了(打很多字是很累的，况且我也知之甚少)，可以去参考相关的文章，这个网上资料比较多了。
今天来探索下 MSSQL 的执行计划，来让大家知道如何查看 MSSQL 的优化机制，以此来优化 SQL 查询。
–DROP TABLE T_UserInfo—————————————————-
– 建测试表
CREATETABLET_UserInfo
(
Userid varchar(20),UserName varchar(20),
RegTimedatetime,Tel varchar(20),
)
– 插入测试数据
DECLARE@IINT
DECLARE@ENDIDINT
SELECT@I=1
SELECT@ENDID = 100– 在此处更改要插入的数据，重新插入之前要删掉所有数据
WHILE@I =@ENDID
BEGIN
INSERTINTOT_UserInfo
SELECT ABCDE +CAST(@IASVARCHAR(20))+ EF , 李 +CAST(@IASVARCHAR(20)),
GETDATE(), 876543 +CAST(@IASVARCHAR(20))
SELECT@I=@I+1
END
– 相关 SQL 语句解释
—————————————————————————
– 建聚集索引
CREATECLUSTEREDINDEXINDEX_UseridONT_UserInfo(Userid)
– 建非聚集索引
CREATENONCLUSTEREDINDEXINDEX_UseridONT_UserInfo(Userid)
– 删除索引
DROPINDEXT_UserInfo.INDEX_Userid
—————————————————————————
—————————————————————————
– 显示有关由 Transact-SQL 语句生成的磁盘活动量的信息
SETSTATISTICSIOON
– 关闭有关由 Transact-SQL 语句生成的磁盘活动量的信息
SETSTATISTICSIOOFF
– 显示[返回有关语句执行情况的详细信息，并估计语句对资源的需求]
SETSHOWPLAN_ALLON
– 关闭[返回有关语句执行情况的详细信息，并估计语句对资源的需求]
SETSHOWPLAN_ALLOFF
—————————————————————————
请记住：SETSTATISTICSIO 和 SETSHOWPLAN_ALL 是互斥的。
OK，现在开始：
首先，我们插入 100 条数据
然后我写了一个查询语句：
SELECT*FROMT_UserInfoWHEREUSERID= ABCDE6EF
选中以上语句，按 Ctrl+L，如下图
这就是 MSSQL 的执行计划：表扫描：扫描表中的行
然后我们来看该语句对 IO 的读写：
执行:SETSTATISTICSIOON
此时再执行该 SQL:SELECT*FROMT_UserInfoWHEREUSERID= ABCDE6EF
切换到消失栏显示如下：
表 T_UserInfo。扫描计数 1，逻辑读 1 次，物理读 0 次，预读 0 次。
解释下其意思：
四个值分别为：
执行的扫描次数;
从数据缓存读取的页数;
从磁盘读取的页数;
为进行查询而放入缓存的页数
重要：如果对于一个 SQL 查询有多种写法，那么这四个值中的逻辑读 (logical reads) 决定了哪个是最优化的。
接下来我们为其建一个聚集索引
执行 CREATECLUSTEREDINDEXINDEX_UseridONT_UserInfo(Userid)
然后再执行 SELECT*FROMT_UserInfoWHEREUSERID= ABCDE6EF
切换到消息栏如下显示：
表 T_UserInfo。扫描计数 1，逻辑读 2 次，物理读 0 次，预读 0 次。
此时逻辑读由原来的 1 变成 2，
说明我们又加了一个索引页，现在我们查询时，逻辑读就是要读两页(1 索引页 + 1 数据页)，此时的效率还不如不建索引。
此时再选中查询语句，然后再 Ctrl+L，如下图:
聚集索引查找：扫描聚集索引中特定范围的行
说明，此时用了索引。
OK, 到这里你应该已经知道初步知道 MSSQL 查询计划和如何查看对 IO 的读取消耗了吧！
接下来我们继续：
现在我再把测试数据改变成 1000 条
再执行 SETSTATISTICSIOON, 再执行
SELECT*FROMT_UserInfoWHEREUSERID= ABCDE6EF
在不加聚集索引的情况下：
表 T_UserInfo。扫描计数 1，逻辑读 7 次，物理读 0 次，预读 0 次。
在加聚集索引的情况下：CREATECLUSTEREDINDEXINDEX_UseridONT_UserInfo(Userid)
表 T_UserInfo。扫描计数 1，逻辑读 2 次，物理读 0 次，预读 0 次。
(其实也就是说此时是读了一个索引页，一个数据页)
如此，在数据量稍大时，索引的查询优势就显示出来了。
先小总结下：
当你构建 SQL 语句时，按 Ctrl+ L 就可以看到语句是如何执行，是用索引扫描还是表扫描？
通过 SETSTATISTICSIOON 来查看逻辑读，完成同一功能的不同 SQL 语句，逻辑读
越小查询速度越快(当然不要找那个只有几百条记录的例子来反我)。
我们再继续深入：
OK，现在我们再来看一次，我们换个 SQL 语句，来看下 MSSQL 如何来执行的此 SQL 呢？
现在去掉索引：DROPINDEXT_UserInfo.INDEX_Userid
现在打开[显示语句执行情况的详细信息]：SETSHOWPLAN_ALLON
然后再执行：SELECT*FROMT_UserInfoWHEREUSERIDLIKE ABCDE8%
看结果栏：结果中有些具体参数，比如 IO 的消耗，CPU 的消耗。
在这里我们只看 StmtText:
SELECT*FROMT_UserInfoWHEREUSERIDLIKE ABCDE8%
|–Table Scan(OBJECT:([student].[dbo].[T_UserInfo]), WHERE:(like([T_UserInfo].[Userid], ABCDE8% , NULL)))
Ctrl+ L 看下此时的图行执行计划：
我再加上索引：
先关闭：SETSHOWPLAN_ALLOFF
再执行：CREATECLUSTEREDINDEXINDEX_UseridONT_UserInfo(Userid)
再开启：SETSHOWPLAN_ALLON
再执行：SELECT*FROMT_UserInfoWHEREUSERIDLIKE ABCDE8%
查看 StmtText:
SELECT*FROMT_UserInfoWHEREUSERIDLIKE 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)Ctrl+ L 看下此时的图行执行计划：
Ctrl+ L 看下此时的图行执行计划：
在有索引的情况下，我们再写一个 SQL：
SETSHOWPLAN_ALLON
SELECT*FROMT_UserInfoWHERELEFT(USERID,4)= ABCDE8%
查看 StmtText:
SELECT*FROMT_UserInfoWHERELEFT(USERID,4)= ABCDE8%
|–Clustered Index Scan(OBJECT:([student].[dbo].[T_UserInfo].[INDEX_Userid]), WHERE:(substring([T_UserInfo].[Userid], 1, 4)= ABCDE8% ))
Ctrl+ L 看下此时的图行执行计划：
我们再分别看一下三种情况下对 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 的优化有初步新的想法了，网上一堆堆的 SQL 优化的文章真的是那样吗？你自己试试就知道了，而不必盲目去记那些东西，自己试试，看看 MSSQL 到底是怎么来执行就明白了。
在我举的例子中，用的是聚集索引扫描，字段是字母加数字，大家可以试试看纯数字的、字母的、汉字的等等，了解下 MMSQL 会如何改变 SQL 语句来利用索引。然后再试试非聚集索引是什么情况？用不用索引和什么有关？子查询 MSSQL 是如何执行？IN 用不用索引，LIKE 用不用索引？函数用不用索引？OR、AND、UNION？子查询呢？在这里我不一一去试给大家看了，只要知道了如何去看 MSSQL 的执行计划（图形和文本)，很多事情就很明朗了。
实现同一查询功能的 SQL 写法可能会有多种，如果判断哪种最优化，如果仅仅是从时间上来测，会受很多外界因素的影响，而我们明白了 MSSQL 如何去执行，通过 IO 逻辑读、通过查看图示的查询计划、通过其优化后而执行的 SQL 语句，才是优化 SQL 的真正途径。
另外提醒下：数据量的多少有时会影响 MSSQL 对同一种查询写法语句的执行计划，这一点在非聚集索引上特别明显，还有就是在多 CPU 与单 CPU 下，在多用户并发情况下，同一写法的查询语句执行计划会有所不同。
看完上述内容，你们掌握 SqlServer 执行计划及 Sql 查询优化的示例分析的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注丸趣 TV 行业资讯频道，感谢各位的阅读！
