zoukankan      html  css  js  c++  java
  • SqlServer 中如何查看某一个Sql语句是复用了执行计划,还是重新生成了执行计划

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

    那么现在我们怎么才能知道执行的Sql语句是复用的SqlServer缓存的执行计划,还是重新生成的执行计划呢?

    我们可以通过Sql Server Profiler这个工具来看到执行计划是否被查询优化器复用。

    首先打开Sql Profiler,新建一个跟踪

    然后在 事件选择 面板上选中 显示所有事件

    然后在事件列表里面,选中 Stored Procedures 类别下的 SP:CacheHit SP:CacheMiss 事件,如果Sql Profiler中出现了SP:CacheHit事件表示SqlServer为查询语句复用了缓存中的执行计划,如果出现了SP:CacheMiss 事件表示SqlServer为查询语句重新生成了执行计划

    接着我们随便执行一个Sql语句如下

    select * from [dbo].[T_People]

    从下图中我们发现在Sql Profiler出现了SP:CacheMiss 事件,因为我们是在SqlServer中第一次执行该查询,所以SqlServer的缓存列表中并没有该查询语句的执行计划,所以SqlServer为该查询语句重新生成了执行计划。

    接着我们再次执行上面的查询语句,这一次Sql Profiler出现了SP:CacheHit  事件,说明SqlServer这次为查询语句复用了缓存中的执行计划,并没有重新生成执行计划。

    使用如下语句可以清除SqlServer目前所有缓存的执行计划,为所有Sql语句重新生成执行计划,切记不要在客户生产环境上执行如下语句!

    DBCC FREEPROCCACHE

    所以通过Sql Profiler我们可以跟踪到执行的每条Sql语句是否重新生成了执行计划,从而知道对查询性能的影响是什么。对于SqlServer是否会为查询语句复用执行计划也是一个非常复杂的问题,诸如查询条件参数化这样的手段都可以增加执行计划的复用性,有兴趣的朋友可以参考下面三篇文章做详细了解,这三篇文章都详细地解释了SqlServer执行计划的复用机制,写的非常全面。

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

    另外关于SqlServer缓存的执行计划何时会被删除找到了下面这篇网摘供参考

    什么情况下会删除执行计划

    在没有人工手动清除缓存的情况下,如果出现内存不足的情况下SQL Server会自动清除一部分没被利用到的缓存计划。

    所有缓存的最大大小取决于max server memory的大小。

    怎样判断需要删除的执行计划

    果存在内存不足的情况,数据库引擎将使用基于开销的方法来确定从过程缓存中删除哪些执行计划。怎样确定一个执行计划的开销呢,对于一个第一次执行的执行计划SQL Server将它的开销值设为0,被多次执行过的执行计划SQL Server将它的开销值设置为原始编译开销,所以数据库引擎会重复检查每个执行计划的状态并将删除当前开销为零的执行计划。如果存在内存不足的情况,当前开销为零的执行计划不会自动被删除,而只有在数据库引擎检查该执行计划并发现其当前开销为零时,才会删除该计划。当检查执行计划时,如果当前没有查询使用该计划,则数据库引擎将降低当前开销以将其推向零。

    数据库引擎会重复检查执行计划,直至删除了足够多的执行计划,以满足内存需求为止。如果存在内存不足的情况,执行计划可多次对其开销进行增加或降低。如果内存不足的情况已经消失,数据库引擎将不再降低未使用执行计划的当前开销,并且所有执行计划都将保留在过程缓存中,即使其开销为零也是如此。

    重新编译执行计划

    根据数据库新状态的不同,数据库中的某些更改可能导致执行计划效率降低或无效。SQL Server 将检测到使执行计划无效的更改,并将计划标记为无效。此后,必须为执行查询的下一个连接重新编译新的计划。导致计划无效的情况包括:

    •对查询所引用的表或视图进行更改(ALTER TABLE 和 ALTER VIEW)。

    •对执行计划所使用的任何索引进行更改。

    •对执行计划所使用的统计信息进行更新,这些更新可能是从语句(如 UPDATE STATISTICS)中显式生成,也可能是自动生成的。

    •删除执行计划所使用的索引。

    •显式调用 sp_recompile。

    •对键的大量更改(其他用户对由查询引用的表使用 INSERT 或 DELETE 语句所产生的修改)。

    •对于带触发器的表,插入的或删除的表内的行数显著增长。

    •使用 WITH RECOMPILE 选项执行存储过程。

  • 相关阅读:
    姐姐的vue(1)
    LeetCode 64. Minimum Path Sum 20170515
    LeetCode 56. 56. Merge Intervals 20170508
    LeetCode 26. Remove Duplicates from Sorted Array
    LeetCode 24. Swap Nodes in Pairs 20170424
    LeetCode 19. Remove Nth Node From End of List 20170417
    LeetCode No.9 Palindrome Number 20170410
    LeetCode No.8. String to Integer (atoi) 2017/4/10(补上一周)
    LeetCode No.7 Reverse Integer 2017/3/27
    LeetCode No.4 Median of Two Sorted Arrays 20170319
  • 原文地址:https://www.cnblogs.com/OpenCoder/p/5819070.html
Copyright © 2011-2022 走看看