执行计划缓存

执行计划编译是需要时间的,为了提高效用率,是要缓存的,可用如下方式查看:
–查看执行计划的缓存

SELECT UseCounts,RefCounts, Cacheobjtype, Objtype,dbid,
ISNULL(DB_NAME(dbid),‘ResourceDB‘) AS DatabaseName, TEXT AS SQL
FROM sys.dm_exec_cached_plans
CROSS APPLY sys.dm_exec_sql_text(plan_handle)
ORDER BY dbid,usecounts DESC;

 SELECT cacheobjtype,objtype,sql FROM sys.syscacheobjects a
 WHERE cacheobjtype = ‘compiled plan‘ AND dbid = 7

–清空执行计划缓存
DBCC FREEPROCCACHE
GO
–从缓存中清除给定数据库的计划缓存
DBCC FLUSHPROCINDB(<dbid>)
GO

执行计划重新编译放到缓存中的时机:
1,表或视图的架构发生了更改,索引发生了改变造成统计信息发生更改。
2,运行了sp_recompile
3,执行计划被清除,如服务器重启,服务重启,放在内存中的执行计划就会被清空。
4,缓存会用LRU算法找出很少使用的,然后从内存中删除,在sys.dm_exec_query_stats中有一字段creation_time标识计划的创建时间,一般一、两个小时就会重新建立一份的。
可通过观察以下事件看缓存的变更。SP:CacheInsert SP:CacheMiss SP:CacheHit

执行计划要保持重用,以提高利用率,可以查出经常重新编译的sql以做优化,当然重用并不一定好,因为执行计划不适合,如参数化问题等。

sys.dm_exec_query_stats 有一个栏位plan_generation_num,计划编译次数,可用此来分析最常编译的计划。
select top 25
    plan_generation_num,
    SUBSTRING(qt.text,qs.statement_start_offset/2+1,
        (case when qs.statement_end_offset = -1
        then DATALENGTH(qt.text)
        else qs.statement_end_offset end -qs.statement_start_offset)/2 + 1)
        as stmt_executing,
    qt.text,
    execution_count,
    sql_handle,
    dbid,
    db_name(dbid) DBName,
    objectid,
    object_name(objectid,dbid) ObjectName
from sys.dm_exec_query_stats as qs
    Cross apply sys.dm_exec_sql_text(sql_handle) qt
where plan_generation_num >1
--AND qs.last_execution_time >=‘2011-08-28 10:00‘ 限定时间
order by plan_generation_num desc
时间: 2024-10-12 21:56:34

执行计划缓存的相关文章

SQL Server 执行计划缓存

原文:SQL Server 执行计划缓存 标签:SQL SERVER/MSSQL SERVER/数据库/DBA/内存池/缓冲区 概述 了解执行计划对数据库性能分析很重要,其中涉及到了语句性能分析与存储,这也是写这篇文章的目的,在了解执行计划之前先要了解一些基础知识,所以文章前面会讲一些概念,学起来会比较枯燥,但是这些基础知识非常重要. 目录 概述 基础概念 怎样缓存执行计划 SQL Server自动删除执行计划 重新编译执行计划 测试 执行计划相关系统视图 手动清空缓存执行计划 测试索引更改对执

SQLServer中的执行计划缓存由于长时间缓存对性能造成的干扰

本文出处:http://www.cnblogs.com/wy123/p/7190785.html (保留出处并非什么原创作品权利,本人拙作还远远达不到,仅仅是为了链接到原文,因为后续对可能存在的一些错误进行修正或补充,无他) 先抛出一个性能问题,前几天遇到一个生产环境性能极其低下的存储过程,开发人员根据具体的业务逻辑和返回的数据量,猜测到这个存储过程的执行应该不会有这么慢.当时意识到可能是执行计划缓存的问题,因为当前这个存储过程的写法还是比较遵守参数化SQL的规范的(如果是动态即席查询SQL就不

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

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

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

原文:谈一谈SQL Server中的执行计划缓存(上) 简介     我们平时所写的SQL语句本质只是获取数据的逻辑,而不是获取数据的物理路径.当我们写的SQL语句传到SQL Server的时候,查询分析器会将语句依次进行解析(Parse).绑定(Bind).查询优化(Optimization,有时候也被称为简化).执行(Execution).除去执行步骤外,前三个步骤之后就生成了执行计划,也就是SQL Server按照该计划获取物理数据方式,最后执行步骤按照执行计划执行查询从而获得结果.但查询

存储过程执行计划缓存查询

SELECT st.Text,SUBSTRING(st.Text, (qs.statement_start_offset/2)+1,((CASE qs.statement_end_offsetWHEN -1 THEN DATALENGTH(st.Text)ELSE qs.statement_end_offsetEND - qs.statement_start_offset)/2)+1),qp.query_plan,qs.plan_handle,qs.sql_handle,DB_NAME(st.d

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

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

参数化(一):计划缓存

很多时候,当我执行查询调优的时候,引发查询性能糟糕的问题一般都是与参数化相关的. 一方面,参数化是查询处理器核心的基本主题.它能显著影响查询性能.另一方面,大家很少对这一主题进行详尽的了解. 因此我准备写一个系列的随笔来介绍关于参数化的问题.第一篇我将介绍关于计划缓存的内容.为了理解参数化,有必要先理解理解执行计划如何被缓存. SQLServer保留一定数量的内存来保存执行计划缓存.这就是执行计划(和一下其他结构)被缓存为了未来重用的地方.查询(或语句)和批处理之间的区别时会引发混淆.前者是作为

执行计划的重用

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

SqlServer 中如何查看某一个Sql语句是复用了执行计划,还是重新生成了执行计划

我们知道SqlServer的查询优化器会将所执行的Sql语句的执行计划作缓存,如果后续查询可以复用缓存中的执行计划,那么SqlServer就会为后续查询复用执行计划而不是重新生成一个新的执行计划,因为复用执行计划的性能比生成执行计划的性能要高很多,所以SqlServer的这一特性可以大大提高Sql语句的执行效率.特别是对于存储过程,因为存储过程的执行计划是在存储过程第一次执行的时候生成的,存储过程的执行计划生成后就会被缓存到SqlServer的执行计划列表中,如果以后存储过程再被执行,那么存储过