执行计划--参数化设置

执行计划与参数化设置
 
当TSQL 语句发送到SQL Server引擎时,SQL 引擎需要对先其进行语法分析检查,然后生成执行计划,再按照执行计划运行并按照指定格式封装结果集返回,TSQL 的运行时间包括生成执行计划的时间和与运行执行计划的时间,SQL Server引擎依据各种索引+约束+统计等数据库对象尝试找出一条够好(执行成本够低的)执行计划。
 
对应复杂的TSQL语句,涉及到众多的表和索引,需要评估多种执行方案,消耗大量CPU资源,并且增加整个语句的执行时间,因此SQL SERVER 使用计划缓存区来缓存执行计划使生成的执行计划可重用。
 
SQLSERVER查询大致分成两类:Ad Hoc 和 Prepared
AdHoc查询指将查询参数直接放入SQL语句中,过滤条件没有明确参数化。
Prepared查询指将查询参数与查询语句独立开来,如使用sp_executesql或存储过程来执行。
 
简单参数化
如果执行不带参数的 SQL 语句,SQL Server 将在内部对该语句进行参数化以增加将其与现有执行计划相匹配的可能性。此过程称为简单参数化。
但在处理复杂的 SQL 语句时,关系引擎可能很难确定哪些表达式可以参数化。
数据库默认使用简单参数化。
如对于语句:

--=====================================================
--清理计划缓存
DBCC FREEPROCCACHE
GO
--=====================================================
--Adhoc 查询
SELECT * FROM dbo.TB3 WHERE object_id=4
--=====================================================
--查看缓存
GO
select cp.usecounts as ‘使用次数‘,cp.cacheobjtype as ‘缓存类型‘,
cp.objtype as [对象类型],st.text as ‘TSQL‘,qp.query_plan as ‘执行计划‘,
cp.size_in_bytes as ‘执行计划占用空间(Byte)‘          
from sys.dm_exec_cached_planscp
cross apply sys.dm_exec_sql_text(plan_handle) st
cross apply sys.dm_exec_query_plan(plan_handle) qp
ORDER BY[对象类型]

由上图可以发现,查询不仅生成了一个 Adhoc 类型的执行计划,生成一个 Prepared 类型的执行计划,而Prepared 类型的执行计划便是SQL SERVER 内部生成的。
再次执行查询:

--=====================================================
--Adhoc 查询
SELECT *FROM dbo.TB3 WHERE object_id=3

查询生成了一个 Adhoc 类型的执行计划,并重用了之前生成的 Prepared 类型的执行计划。
 
强制参数化
通过指定将数据库中的所有 SELECT、INSERT、UPDATE和 DELETE 语句参数化,可以覆盖 SQL Server 的默认简单参数化行为。
当数据库启动强制参数化后,DML语句中出现的任何文本值都将在查询编译期间转换成参数(部分情况下例外)。
强制参数化可以解决那些简单参数化选项下无法参数化的复杂语句。

--===========================================================
--将数据库设置为强制参数化
USE [master]
GO
ALTER DATABASE [DB0003] SET PARAMETERIZATION FORCEDWITH NO_WAIT
GO
optimizefor ad hoc workloads

“针对即席工作负荷进行优化”选项用于提高包含许多一次性临时批处理的工作负荷计划缓存的效率。如果该选项设置为 1,则数据库引擎将在首次编译批处理时在计划缓存中存储一个编译的小计划存根,而不是存储完全编译的计划,这样避免缓存那些不会再重复使用的执行计划,缓解内存压力。

--=====================================================
--启用optimize for ad hoc workloads
SELECT * FROM sys.configurations
WHERE name=‘optimize for ad hocworkloads‘
GO
SP_CONFIGURE ‘optimize for ad hoc workloads‘,1
GO
RECONFIGURE

在运行以下语句:
--=====================================================
--Adhoc 查询
SELECT *FROM dbo.TB3 WHERE object_id=3

第一次执行后只会存储执行计划存根,只占用232 Byte的内存
再次执行一遍后才存储执行计划,使用24576 Byte的内存。


 
总结:
1>虽然可以使用“简单参数化”或“强制参数化”来优化 adhoc 查询,重用执行计划,但是仍会造成一定的性能损耗,对于重复执行的语句,还是应该将之参数化。
2>当大量只执行一次的adhoc 查询语句出现时,可以使用 optimize for ad hoc workloads 来减少计划缓存使用的内存。
参考链接:
http://msdn.microsoft.com/zh-tw/library/dn168870.aspx
http://technet.microsoft.com/zh-cn/library/ms186219.aspx
http://technet.microsoft.com/zh-cn/library/ms175037(v=sql.105).aspx
http://technet.microsoft.com/zh-cn/library/cc645587(v=sql.105).aspx
 
 
 ***********转摘:https://www.cnblogs.com/TeyGao/p/3526804.html

原文地址:https://www.cnblogs.com/linybo/p/11445758.html

时间: 2024-08-11 05:44:53

执行计划--参数化设置的相关文章

Oracle执行计划与统计信息的一些总结

[日期:2011-08-05]来源:Linux社区  作者:wangshengfeng1986211[字体:大 中 小] 2010-07-01 15:03 1.SET AUTOTRACE ON EXPLAIN(set autot on exp)SQLPLUS的命令,在执行SQL语句的同时显示执行计划,设置EXP(LAIN)的目的是只显示执行计划而不显示统计信息..2.SQL>explain plan for select ````````;SQL>select * from table(dbm

SQL Sever 2008性能分析之执行计划

一直想找一些关于SQL语句性能调试的权威参考,但是有参考未必就能够做好调试 2的工作.我深信实践中得到的经验是最珍贵的,书本知识只是一个引导.本篇来源于<Inside Microsoft SQL Server 2008>,有经验的高手尽管拍砖把. 这个部分将讲解一些性能分析工具,这些性能分许主要关注在执行计划. 缓存执行计划  SQL Server 2008提供了一些服务器对象来分析执行计划Sys.dm_exec_cached_plans:    包含缓存的执行计划,每个执行计划对应一行.Sy

SQL 执行计划(一)

缓存执行计划  SQL Server 2008提供了一些服务器对象来分析执行计划Sys.dm_exec_cached_plans:    包含缓存的执行计划,每个执行计划对应一行.Sys.dm_exec_plan_attributes: 这是一个系统函数,每一个执行计划都对应着一些属性,在这个系统函数中包含着这些属性.Sys.dm_exec_sql_text:             这是一个系统函数,返回文字格式的执行计划.Sys.dm_exec_query_plan:        这是一个

SQL性能分析之执行计划

一直想找一些关于SQL语句性能调试的权威参考,但是有参考未必就能够做好调试的工作.我深信实践中得到的经验是最珍贵的,书本知识只是一个引导.本篇来源于<Inside Microsoft SQL Server 2008>,有经验的高手尽管拍砖把. 这个部分将讲解一些性能分析工具,这些性能分许主要关注在执行计划. 缓存执行计划  SQL Server 2008提供了一些服务器对象来分析执行计划Sys.dm_exec_cached_plans:    包含缓存的执行计划,每个执行计划对应一行.Sys.

SQL点滴27—性能分析之执行计划

原文:SQL点滴27-性能分析之执行计划 一直想找一些关于SQL语句性能调试的权威参考,但是有参考未必就能够做好调试的工作.我深信实践中得到的经验是最珍贵的,书本知识只是一个引导.本篇来源于<Inside Microsoft SQL Server 2008>,有经验的高手尽管拍砖把. 这个部分将讲解一些性能分析工具,这些性能分许主要关注在执行计划. 缓存执行计划  SQL Server 2008提供了一些服务器对象来分析执行计划Sys.dm_exec_cached_plans:    包含缓存

SQL Server中参数化SQL写法遇到parameter sniff ,导致不合理执行计划重用的一种解决方案

parameter sniff问题是重用其他参数生成的执行计划,导致当前参数采用该执行计划非最优化的现象.想必熟悉数据的同学都应该知道,产生parameter sniff最典型的问题就是使用了参数化的SQL(或者存储过程中使用了参数化)写法,如果存在数据分布不均匀的情况下,正常情况下生成的执行计划,在传入在分布数据较多的参数的情况下,重用了正常参数生成的执行计划,而这种缓存的执行计划并非适合当前参数的一种情况. 这种情况,在实际业务中,出现的频率还是比较高的,因为存储过程一般都是采用参数化的写法

unix中无法使用crontab设置执行计划

unix中无法使用crontab设置执行计划 在系统下进行crontab设置时出现如下几种现象: 解决方法: 编辑cron文件内容: #EDITOR=vi #export EDITOR         (将VI设成缺省的文件编辑器) 这样的话当你编辑任务的时候,默认的编辑器就是 vi 了(注意:如果重新登陆的话,还得重新设定,但可以将语句加入到环境变量中,这样每次启机后都可以直接使用了) #crontab –e            (编辑当前用户的cron文件) #crontab –e use

执行计划的重用

当查询被提交时,SQL Server检查过程缓冲中匹配的执行计划,如果没有找到,SQL Server执行查询编译和优化以生成新的执行计划. 如果执行计划存在于缓冲中,它在私有的执行上下文中重用,这节约了CPU的编译和优化周期. 具有不同过滤条件的相同查询提交到SQL Server时,如: SELECT * FROM Person WHERE Id = 1 当这个查询被提交时,优化器创建一个执行计划并将其存储在过程缓冲中以被将来重用.如果这个查询使用不同的过滤条件,如:WHERE Id = 2重新

谈一谈SQL Server中的执行计划缓存(下)

简介 在上篇文章中我们谈到了查询优化器和执行计划缓存的关系,以及其二者之间的冲突.本篇文章中,我们会主要阐述执行计划缓存常见的问题以及一些解决办法. 将执行缓存考虑在内时的流程 上篇文章中提到了查询优化器解析语句的过程,当将计划缓存考虑在内时,首先需要查看计划缓存中是否已经有语句的缓存,如果没有,才会执行编译过程,如果存在则直接利用编译好的执行计划.因此,完整的过程如图1所示. 图1.将计划缓存考虑在内的过程 图1中我们可以看到,其中有一步需要在缓存中找到计划的过程.因此不难猜出,只要是这一类查