主页 / dba / 问题 / 232449
Accepted
Marc S
Asked: 2019-03-19 08:48:55 +0800 CST

参数化计划刷新

  • 772

我无法在任何地方找到有关触发此重新编译原因的文档。我们正在调查突然的查询性能下降，我唯一能想到的是，在针对小型数据集执行时，计划为参数化查询重新编译，导致行估计混乱。我们注意到，当这个进程运行时（在它开始花费数小时而不是数秒之后）它对 tempdb 的影响非常大。消耗表的统计数据未更改，重新编译原因列表中唯一有意义的其他原因是#12“参数化计划已刷新”。

有问题的过程是在单个 INT 列上调用视图和过滤。这是通过实体框架完成的。类上只有1个Entity Key，是视图中主表的PK。所有记录都是独一无二的。

我很好奇是否有人可以向我指出那里的任何文档，这些文档解释了为什么可能由于“参数化计划刷新”而重新编译计划。

sql-server-2016 plan-cache

1 个回答

  1. Best Answer

    查询计划由于多种原因从缓存中刷新，包括老化、由于内存压力而刷新、由于用户操作（DBCC FREEPROCCACHE 等）而刷新、由于重新启动而刷新以及由于显式重新编译（选项（RECOMPILE 或 sp_recompile）而刷新).

    如果您看不到强制重新编译或手动刷新的证据，那么很可能是该计划已过时或由于内存压力而被刷新。来自文档：Plan Cache Internals：

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

    • I/O：每个 I/O 花费 1 个 tick，最多 19 个。
    • 上下文切换：每个 1 个刻度，最多 8 个。
    • 内存：每 16 页 1 个刻度，最多 4 个。

    当没有内存压力时，成本不会降低，直到缓存的所有计划的总大小达到缓冲池大小的 50%。那时，下一个计划访问将使所有计划的成本减 1。一旦遇到内存压力，SQL Server 将启动一个专用的资源监视器线程来减少一个特定缓存中任一计划对象的成本（对于本地压力）或所有计划缓存对象（用于全局压力）。

    看看这个StackExchange 答案，它提供了大量关于计划重用和缓存的重要链接和信息。如果这种情况再次发生，您必须实施监控以找出确切原因，但您还应该考虑利用查询存储，这将允许您为此查询强制执行已知的良好计划并跟踪整个数据库的回归，因为这可能是也会影响其他查询。

    • 4

相关问题