参数化冲图

Question

在触发重新编译原因的任何地方，我都找不到文档。我们正在调查一个突然的查询性能下降，我唯一能想到的是，当对一个小数据集执行参数化查询时，计划被重新编译，这会导致行估计的混乱。我们注意到，当这个进程正在运行时(在它开始运行几个小时而不是几秒钟之后)，它对tempdb的打击相当大。消耗表的统计信息没有被更改，在重新编译原因列表中唯一有意义的其他原因是#12“参数化计划刷新”。

所讨论的过程是对单个INT列调用视图和筛选。这是通过实体框架完成的。类上只有一个实体键，它是视图中主表的PK。所有的记录都是独一无二的。

我很好奇是否有人能向我指出任何文档，解释为什么一个计划可能会因为“参数化的计划刷新”而被重新编译。

Answer 1

查询计划因以下几个原因而从缓存中刷新:老化、内存压力刷新、用户操作刷新(等)、重新启动刷新和显式重新编译(选项(重新编译或sp_recompile) )。

如果您没有看到强迫重新编译或手动刷新的证据，那么很可能计划已经过期，或者由于内存压力而被刷新。来自文档:计划缓存内部来自文档:计划缓存内部：

将计划逐出缓存是基于它们的成本。对于临时计划，成本被认为是零，但每次该计划被重复使用时，它会增加一个。对于其他类型的计划，成本是衡量制定计划所需的资源。当这些计划中的一个被重用时，成本将重置为原始成本。对于非即席查询，成本以称为滴答( ticks )的单位来衡量，最高为31。成本基于三个因素: I/O、上下文切换和内存。每个人在31勾总数内都有自己的最大值。

• I/O:每次输入/输出只需1次，最多19次。
• 上下文开关:1勾，最多8。
• 内存:每16页1次，最多4页。

在不受内存压力的情况下，在缓存的所有计划的总大小达到缓冲池大小的50 %之前，成本不会降低。此时，下一次计划访问将降低所有计划的成本1。一旦遇到内存压力，SQL Server将启动专用资源监视线程，以降低一个特定缓存中的计划对象(本地压力)或所有计划缓存对象(用于全局压力)的成本。

看看这个StackExchange答案，它提供了大量关于计划重用和缓存的链接和信息。如果再次发生这种情况，您必须进行监视，以捕获确切原因，但您还应该考虑利用查询存储，这将使您能够强制执行一个已知的查询计划，并跟踪数据库中的回归，因为这可能也会影响其他查询。