引用:初探Sql Server 执行计划及Sql查询优化

时间:2022-02-21 23:01:59

原文:引用:初探Sql Server 执行计划及Sql查询优化

初探Sql Server 执行计划及Sql查询优化 收藏

MSSQL优化之————探索MSSQL执行计划

作者:no_mIss

最近总想整理下对MSSQL的一些理解与感悟,却一直没有心思和时间写,晚上无事便写了一篇探索MSSQL执行计划,本文讲执行计划但不仅限于讲执行计划。

网上的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,如下图

引用:初探Sql Server 执行计划及Sql查询优化

这就是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,如下图:

引用:初探Sql Server 执行计划及Sql查询优化

聚集索引查找:扫描聚集索引中特定范围的行

说明,此时用了索引。

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看下此时的图行执行计划:

引用:初探Sql Server 执行计划及Sql查询优化

我再加上索引:

先关闭: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 Server 执行计划及Sql查询优化

在有索引的情况下,我们再写一个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看下此时的图行执行计划:

引用:初探Sql Server 执行计划及Sql查询优化

我们再分别看一下三种情况下对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认识还很浅薄,如有不对的地方,还请指正。

引用:初探Sql Server 执行计划及Sql查询优化的更多相关文章

  1. SQL Server 执行计划缓存

    标签:SQL SERVER/MSSQL SERVER/数据库/DBA/内存池/缓冲区 概述 了解执行计划对数据库性能分析很重要,其中涉及到了语句性能分析与存储,这也是写这篇文章的目的,在了解执行计划之 ...

  2. SQL Server 执行计划操作符详解(3)——计算标量&lpar;Compute Scalar&rpar;

    接上文:SQL Server 执行计划操作符详解(2)--串联(Concatenation ) 前言: 前面两篇文章介绍了关于串联(Concatenation)和断言(Assert)操作符,本文介绍第 ...

  3. sql server 执行计划&lpar;execution plan&rpar;介绍

    大纲:目的介绍sql server 中执行计划的大致使用,当遇到查询性能瓶颈时,可以发挥用处,而且带有比较详细的学习文档和计划,阅读者可以按照我计划进行,从而达到对执行计划一个比较系统的学习. 什么是 ...

  4. SQL Server 执行计划中的扫描方式举例说明

    SQL Server 执行计划中的扫描方式举例说明 原文地址:http://www.cnblogs.com/zihunqingxin/p/3201155.html 1.执行计划使用方式 选中需要执行的 ...

  5. SQL Server执行计划那些事儿(3)——书签查找

    接下来的文章是记录自己曾经的盲点,同时也透漏了自己的发展历程(可能发展也算不上,只能说是瞎混).当然,一些盲点也在工作和探究过程中慢慢有些眉目,现在也愿意发扬博客园的奉献精神,拿出来和大家分享一下. ...

  6. SQL Server执行计划那些事儿(2)——查找和扫描

    接下来的文章是记录自己曾经的盲点,同时也透漏了自己的发展历程(可能发展也算不上,只能说是瞎混).当然,一些盲点也在工作和探究过程中慢慢有些眉目,现在也愿意发扬博客园的奉献精神,拿出来和大家分享一下. ...

  7. SQL Server 执行计划操作符详解(2)——串联&lpar;Concatenation &rpar;

    本文接上文:SQL Server 执行计划操作符详解(1)--断言(Assert) 前言: 根据计划,本文开始讲述另外一个操作符串联(Concatenation),读者可以根据这个词(中英文均可)先幻 ...

  8. SQL Server 执行计划分析

    当一个查询到达数据库引擎时,SQL Server执行两个主要的步骤来产生期望的查询结果: 第一步:查询编译,生成查询计划. 第二步:执行这个查询计划. 1. 用于演示分析执行计划的查询语句 /* 查询 ...

  9. SQL SERVER 执行计划各字段注释

    SET SHOWPLAN_ALL使 Microsoft® SQL Server™ 不执行 Transact-SQL 语句.相反,SQL Server 返回有关语句执行方式和语句预计所需资源的详细信息. ...

随机推荐

  1. HTTP中的POST、GET区别

    Http定义了与服务器交互的不同方法,最基本的方法有4种,分别是GET,POST,PUT,DELETE.URL全称是资源描述符,我们可以这样认为:一个URL地址,它用于描述一个网络上的资源,而HTTP ...

  2. NOIP2013 花匠

    题目描述 花匠栋栋种了一排花,每株花都有自己的高度.花儿越长越大,也越来越挤.栋栋决定 把这排中的一部分花移走,将剩下的留在原地,使得剩下的花能有空间长大,同时,栋栋希 望剩下的花排列得比较别致. 具 ...

  3. Android 如何在Eclipse中查看Android API源码 及 support包源码

    当我们阅读android API开发文档时候,上面的每个类,以及类的各个方法都是已经写好的方法和控件,可是我们只是在搬来使用,不知道它的原理,它是如何被实现的.android系统是开源的,所以谷歌官方 ...

  4. zookeeper系列之十一—zookeeper会话超时

    1.会话概述 在Zookeeper中,客户端和服务端建立连接后,会话随之建立,生成一个全局唯一的会话ID(Session ID).服务器和客户端之间维持的是一个长连接,在SEESSION_TIMEOU ...

  5. highcharts联合jquery ajax 后端取数据

    Highcharts是一个制作图表的纯Javascript类库,主要特性如下: 兼容性:兼容当今所有的浏览器,包括iPhone.IE和火狐等等: 对个人用户完全免费: 纯JS,无BS: 支持大部分的图 ...

  6. TC srm 673 300 div1

    TC srm.673 300 Time Limit: 20 Sec Memory Limit: 256 MB 题目连接 Description 给你n(n<=50)匹马和n个人,一匹马和一个人能 ...

  7. 解决VS报表&period;rdl 显示乱码&OpenCurlyDoubleQuote;小方块”问题

    报表在编辑状态显示文本显示小方块 如图 原因:字体格式是英文状态下. 解决:选中文本框,选择文本框属性,选择字体,字体改成宋体或微软雅黑.就可以了.

  8. 框架源码系列八:Spring源码学习之Spring核心工作原理(很重要)

    目录:一.搞清楚ApplicationContext实例化Bean的过程二.搞清楚这个过程中涉及的核心类三.搞清楚IOC容器提供的扩展点有哪些,学会扩展四.学会IOC容器这里使用的设计模式五.搞清楚不 ...

  9. js條件結構和循環結構

    條件結構: if(語句1) if(語句1)else(語句2) if(語句1)elseif(語句2)else(語句3) switch結構: switch() { case 1: break: case ...

  10. Modern Data Lake with Minio &colon; Part 1

    转自:https://blog.minio.io/modern-data-lake-with-minio-part-1-716a49499533 Modern data lakes are now b ...