北京pk赛车官网下载SQL参数化查询的另二个理由,MSSQL优化实施安顿

1概述
SQL语言的本质就是一串伪代码,表达的是做什么,而不是怎么做的意思。如其它语言一样,SQL语句需要编译之后才能运行,所以每一条SQL是需要通过编译器解释才能运行的(在这之间还要做SQL的优化)。而这些步骤都是需要运行成本,所以在数据库中有一个叫做执行计划的东西,编译器会将编译过后的SQL存入执行计划当中,当遇到同样的SQL时,就直接调用执行计划来执行,而不需要再次编译。
通过对上面执行计划的认识,为了提高数据库运行的效率,我们需要尽可能的命中执行计划,这样就可以节省运行时间。
2相关SQL 2.1查看当前数据库中所有的执行计划: 复制代码 代码如下: SELECT cp.usecounts AS
‘使用次数’ ,objtype AS ‘类型’ ,st.[text] AS ‘SQL文本’ ,plan_handle AS
‘计划句柄’ FROM sys.dm_exec_cached_plans cp CROSS APPLY
sys.dm_exec_sql_text(plan_handle) AS st WHERE st.text not like
‘%sys%’ 2.2删除执行计划 复制代码
代码如下: –删除所有计划 DBCC FREEPROCCACHE 2.3测试脚本 复制代码 代码如下: IF EXISTS (SELECT * FROM
sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[Employee]’)) DROP
TABLE [dbo].Employee GO –人员表 CREATE TABLE dbo.Employee ( id int,
name nvarchar(50) ); –插入测试数据 DECLARE @I INT=0,@ENDI INT=1000;
WHILE(@I@ENDI) BEGIN SET @I+=1; INSERT dbo.Employee(id,name)
VALUES(@I,’蒋大华’+CAST(@I AS NVARCHAR(20))); END;

存储过程是一组为了完成特定功能的sql语句集,经编译后存储在数据库中,每次调用使用过程名并给出参数来执行

介绍了关于利用MSSQL执行计划来优化mssql数据库哦,有需要的朋友参考一下。

3测试执行计划

优点:
1 速度快,性能好,
重复使用它的缓存执行计划,节省了分析解析它的服务器资源和时间

今天来探索下MSSQL的执行计划,来让大家知道如何查看MSSQL的优化机制,以此来优化SQL查询。

3.1 先执行删除所有执行计划,然后执行SELECT * FROM Employee
,最后查看执行计划如下图

2 减少网络流量
3
安全性强,参数化的过程更安全,减少sql攻击,可以通过校验参数,属于对象执行权限提高了安全性

代码如下复制代码

即SQL SERVER会为每一条SQL建立一个执行计划,并将它缓存起来

4 业务逻辑封装

–DROP TABLE
T_UserInfo—————————————————-

3.2 再运行一次SQL: SELECT * FROM Employee,并查看执行计划

存储过程分类
一般分为:
系统存储过程,一般以sp开头命名,扩展存储过程,一般以xp开头命名,
用户存储过程
(我一般以usp开头名称),用户存储过程也包括临时存储过程(又分为全局临时过程,局部临时过程)

–建测试表

可以看到这个计划的重用次数为2,即这个计划被重用了;

创建过程前先判断:
IF OBJECT_ID(N’dbo.USP_GetEmployeById’) IS NOT NULL
BEGIN
DROP PROC dbo.USP_GetEmployeById;
END
GO

CREATE TABLE T_UserInfo

3.3 修改SQL:SELECT * FROM Employee,执行并查看执行计划

IF (@EmployeeName IS NULL OR LEN(@EmployeeName) =0)

(

结果又新添加一个执行计划,即SQL
SERVER认为这是两个不同的SQL语句并分别建立了执行计划;

相当于C#的string.IsNullOrEmpty(@EmployeeName)

Userid varchar(20), UserName varchar(20),

4重用执行计划——使用参数化查询方法

IF @@error = 0 受影响的行数

RegTime datetime, Tel varchar(20),

4.1 未参数化SQL复制代码 代码如下: string
selectCmdText = string.Format(@”SELECT * FROM Employee WHERE
name='{0}'”,” 蒋大华1”);
SQLHelper.ExecuteNonQuery(SQLHelper.DefaulConnectiontString,
System.Data.CommandType.Text, selectCmdText, null); 查看执行计划:

BEGIN TRY

)

即当执行一个未参数化SQL时,SQL
SERVER需要先将其转换成一个参数SQL并执行它。一共需要两执行计划

END TRY

–插入测试数据

然后再执行下面的代码复制代码 代码如下:
string selectCmdText = string.Format(@”SELECT * FROM Employee WHERE
name='{0}'”,” 蒋大华2”);
SQLHelper.ExecuteNonQuery(SQLHelper.DefaulConnectiontString,
System.Data.CommandType.Text, selectCmdText, null); 查看执行计划

BEGIN CATCH
END CATCH

DECLARE @I INT

此时不需要再准备一个准备的SQL,但还是需要再产生一个执行计划,并缓存下来;

这玩意相当于c#的
try{ } catch (Exception){ throw; }

DECLARE @ENDID INT

4.2 参数化SQL复制代码 代码如下:
SqlParameter[] param = { new SqlParameter(“@name”,
txtEmployeeName.Text.Trim()) }; string selectCmdText =
string.Format(@”SELECT * FROM Employee WHERE name=@name”);
SQLHelper.ExecuteNonQuery(SQLHelper.DefaulConnectiontString,
System.Data.CommandType.Text, selectCmdText, param);

这样添加一个存储过程的输出参数

SELECT @I = 1

输入参数并执行,然后查看执行计划:

DECLARE @Result NVARCHAR(4);

SELECT @ENDID = 100 –在此处更改要插入的数据,重新插入之前要删掉所有数据

只需要一个准备SQL,然后,输入不同的参数,并执行,再查看执行计划

复制代码

WHILE @I = @ENDID

重用执行计划,perfect…

SET @Result = ”;
EXEC dbo.USP_AddEmploye
@EmployeeName =’张飞’,
@Sex =1 ,
@Department = ‘市场部’,
@Success = @Result OUTPUT

BEGIN

5总结

SELECT @Result;

INSERT INTO T_UserInfo

总的来说,SQL语句在执行时,会生成执行计划并将它缓存起来,我们可以通过提高使用缓存中的执行计划次数,来减少数据库的压力。而使用参数化的SQL是一个很好的选择,参数化查询的作用不仅只有防止SQL注入,还可以提高缓存中执行计划使用次数。

一般在执行存储过程是,最好加上架构名称,例如:dbo.USP_AddEmploye
这样可以可以减少不必要的系统开销,提高性能。
因为如果在存储过程名称前面没有加上架构名称、SQL SERVER
首先会从当前数据库sys
schema开始查找,如果没有找到,则会去其它schema查找,最后在dbo架构里面查找。

SELECT ‘ABCDE’+CAST(@I AS VARCHAR(20))+’EF’,’李’+CAST(@I AS
VARCHAR(20)),

查询过程创建成功后的信息

GETDATE(),’876543’+CAST(@I AS VARCHAR(20))

SELECT * FROM SYS.SQL_MODULES WHERE object_id
=OBJECT_ID(N’dbo.usp_Test’)

SELECT @I = @I + 1

存储过程引用的表对象不需要在创建该存储过程时就存在,而只需在执行该存储过程时存在。这个叫延迟名称解析

END

 

–相关SQL语句解释

SP_HELP ‘dbo.USP_GetEmployeById’ –查看存储过程的基本信息:例如参数等


SP_HELPTEXT ‘dbo.USP_GetEmployeById’ –查看具体的存储过程

–建聚集索引

SELECT * FROM SYS.SQL_MODULES WHERE object_id
=OBJECT_ID(N’dbo.USP_GetEmployeById’) –查看具体的存储过程

CREATE CLUSTERED INDEX INDEX_Userid ON T_UserInfo (Userid)

 

–建非聚集索引

SP_HELP ‘[dbo].[Pr_Test]’ –查看存储过程的基本信息:例如参数等

CREATE NONCLUSTERED INDEX INDEX_Userid ON T_UserInfo (Userid)

SP_HELPTEXT ‘[dbo].[Pr_Test]’ –查看具体的存储过程

–删除索引

SELECT * FROM SYS.SQL_MODULES WHERE object_id
=OBJECT_ID(N'[dbo].[Pr_Test]’) –查看具体的存储过程

DROP INDEX T_UserInfo.INDEX_Userid

 


存储过程的加密
它一般通过关键字ENCRYPTION 来实现


SQL Server 将 CREATE PROCEDURE
语句的原始文本转换为模糊格式。模糊代码的输出在 SQL Server 2005
的任何目录视图中都不能直接显示。对系统表或数据库文件没有访问权限的用户不能检索模糊文本。但是,可通过
DAC
端口访问系统表的特权用户或直接访问数据库文件的特权用户可使用此文本。此外,能够向服务器进程附加调试器的用户可在运行时从内存中检索已解密的过程。

–显示有关由Transact-SQL 语句生成的磁盘活动量的信息

–过程加密
CREATE PROCEDURE dbo.USP_GetEmployeById
@EmployeeID INT = -1,
@EmployeeName NVARCHAR(30) = NULL
WITH ENCRYPTION
AS

SET STATISTICS IO ON

SET NOCOUNT ON;

–关闭有关由Transact-SQL 语句生成的磁盘活动量的信息

BEGIN

SET STATISTICS IO OFF

IF (@EmployeeID = -1 AND @EmployeeName IS NULL)
BEGIN
PRINT ‘请输入员工ID号或是用户名字’;
END

–显示[返回有关语句执行情况的详细信息,并估计语句对资源的需求]

IF @EmployeeID = -1
SELECT * FROM dbo.Employee WHERE EmployeeName = @EmployeeName;
ELSE
SELECT * FROM dbo.Employee WHERE EmployeeID = @EmployeeID;

SET SHOWPLAN_ALL ON

END
GO

–关闭[返回有关语句执行情况的详细信息,并估计语句对资源的需求]

解密:
在网上找国外大牛写的解密加密存储过程的一个存储过程usp_decrypt

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%’))

我们再分别看一下三种情况下对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的真正途径。

发表评论

电子邮件地址不会被公开。 必填项已用*标注