MSSQL优化之探索MSSQL执行计划（转）
程序员文章站
2023-12-05 18:19:58
网上的sql优化的文章实在是很多，说实在的，我也曾经到处找这样的文章，什么不要使用in了，什么or了，什么and了，很多很多，还有很多人拿出仅几s甚至几ms的时间差的例子来...
网上的sql优化的文章实在是很多，说实在的，我也曾经到处找这样的文章，什么不要使用in了，什么or了，什么and了，很多很多，还有很多人拿出仅几s甚至几ms的时间差的例子来证明着什么(有点可笑)，让许多人不知道其是对还是错。而sql优化又是每个要与数据库打交道的程序员的必修课，所以写了此文，与朋友们共勉。
谈到优化就必然要涉及索引，就像要讲锁必然要说事务一样，所以你需要了解一下索引，仅仅是索引，就能讲半天了，所以索引我就不说了(打很多字是很累的，况且我也知之甚少)，可以去参考相关的文章，这个网上资料比较多了。
今天来探索下mssql的执行计划，来让大家知道如何查看mssql的优化机制，以此来优化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
--相关sql语句解释
---------------------------------------------------------------------------
--建聚集索引
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'
选中以上语句，按ctrl+l，如下图
这就是mssql的执行计划：表扫描：扫描表中的行
然后我们来看该语句对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数据页)，此时的效率还不如不建索引。
此时再选中查询语句，然后再ctrl+l，如下图:
聚集索引查找：扫描聚集索引中特定范围的行
说明，此时用了索引。
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)))
ctrl+l看下此时的图行执行计划：
我再加上索引：
先关闭：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)ctrl+l看下此时的图行执行计划：
ctrl+l看下此时的图行执行计划：
在有索引的情况下，我们再写一个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%'))
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下，在多用户并发情况下，同一写法的查询语句执行计划会有所不同，这个就需要大家有机会去试验了(我也没有这方面的太多经验与大家分享)。
先写这些吧，由于我对mssql认识还很浅薄，如有不对的地方，还请指正。
谈到优化就必然要涉及索引，就像要讲锁必然要说事务一样，所以你需要了解一下索引，仅仅是索引，就能讲半天了，所以索引我就不说了(打很多字是很累的，况且我也知之甚少)，可以去参考相关的文章，这个网上资料比较多了。
今天来探索下mssql的执行计划，来让大家知道如何查看mssql的优化机制，以此来优化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
--相关sql语句解释
---------------------------------------------------------------------------
--建聚集索引
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'
选中以上语句，按ctrl+l，如下图
这就是mssql的执行计划：表扫描：扫描表中的行
然后我们来看该语句对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数据页)，此时的效率还不如不建索引。
此时再选中查询语句，然后再ctrl+l，如下图:
聚集索引查找：扫描聚集索引中特定范围的行
说明，此时用了索引。
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)))
ctrl+l看下此时的图行执行计划：
我再加上索引：
先关闭：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)ctrl+l看下此时的图行执行计划：
ctrl+l看下此时的图行执行计划：
在有索引的情况下，我们再写一个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%'))
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下，在多用户并发情况下，同一写法的查询语句执行计划会有所不同，这个就需要大家有机会去试验了(我也没有这方面的太多经验与大家分享)。
先写这些吧，由于我对mssql认识还很浅薄，如有不对的地方，还请指正。