通常 sp_execute sql 将重用缓存计划，其中 EXEC 将为每个参数创建新计划。
在此示例中，两个查询都使用 sp_executesql - 第二个查询导致计划缓存中计划数量减少的原因是什么？
查询一：
查询 2：
我无法在任何地方找到有关触发此重新编译原因的文档。我们正在调查突然的查询性能下降，我唯一能想到的是，在针对小型数据集执行时，计划为参数化查询重新编译，导致行估计混乱。我们注意到，当这个进程运行时（在它开始花费数小时而不是数秒之后）它对 tempdb 的影响非常大。消耗表的统计数据未更改，重新编译原因列表中唯一有意义的其他原因是#12“参数化计划已刷新”。
有问题的过程是在单个 INT 列上调用视图和过滤。这是通过实体框架完成的。类上只有1个Entity Key，是视图中主表的PK。所有记录都是独一无二的。
我很好奇是否有人可以向我指出那里的任何文档，这些文档解释了为什么可能由于“参数化计划刷新”而重新编译计划。
有没有办法找到一个过程最后一次在 Sybase ASE 16 中编译执行计划的时间？
我在 sysobjects 中没有看到“修改过的”日期时间列，而且我一直无法找到与可查询计划缓存等效的 Sybase 来查看它是否有日期。
我的经理要求知道最后一次运行一些报告以查看它们是否被使用是什么时候。他要求我们的供应商和供应商提供信息，如果来找我获得 SA 级别的权限以挖掘相关的 SQL Server。
显然，我不会这样做，但我想知道有没有办法跟踪特定查询的最后一次执行时间？
这个数据库驻留在旧的 SQL Server 2008 R2 安装上，所以我确信我的选择是有限的，如果不是不存在的话，特别是因为他想回顾 18 个月。
只是想我会问，以防至少有部分方法可以追溯到历史并跟踪这些信息。
存储过程的缓存中缺少计划的原因是什么？
WITH RECOMPILE- 动态 SQL
- 加密代码
- 重大数据变化
- 更新统计
- 还有什么？
我最近在 2 台服务器（SQL Server 2008 R2 和 SQL Server 2012）上工作过，这些服务器没有针对资源密集型存储过程的缓存计划。存储过程中的许多（也许是全部）语句也没有缓存中的计划。一些存储过程非常频繁地执行，例如每秒几次。
没有任何记忆压力。其中一台服务器的硬件比需要的多得多。
我认为缺少计划是由于在存储过程中间创建了临时表，但这似乎是 SQL Server 2000 或更早版本的旧信息。从 SQL Server 2005 开始，重新编译发生在 DDL 之后的语句的语句级别。在所有情况下都是如此，还是在较新的版本上仍然会发生？
还有什么可能是缺少计划的罪魁祸首？我浏览了几篇关于这个主题的文章，但似乎没有什么合适的。
我本周正在查看的服务器上启用了针对临时工作负载的优化。其中一个存储过程每天只执行一次。我确实有那个的代码。我没有每分钟执行超过 100 次的代码，但我可以得到它。我将无法发布代码，但我可以根据我的问题对其进行描述。
我不相信有人在释放过程缓存或删除干净的缓冲区。该客户使用 Solarwinds DPA 作为其监控工具之一。DPA 确实捕获了每天调用一次的存储过程中的语句的执行计划之一。WHERE由于 non-sargable子句，该语句具有大量读取。如果 DPA 捕获了该语句，那么它是一个估计的计划，并且曾经在计划缓存中。只是在我们进行故障排除时不在那里。我会让他们开始记录sp_WhoIsActive到一张桌子上。
我正在使用sp_BlitzCache. （我为 Brent Ozar Unlimited 工作）这将显示整个存储过程的计划以及单个语句的计划（如果存在）。如果它们不存在，则会出现警告“我们找不到此查询的计划。可能的原因包括动态 SQL、RECOMPILE提示和加密代码。” 该警告也在声明中。
TF 2371 没有到位。我正在查看等待统计数据。服务器很无聊。PLE 超过 130,000。
我现在有另外 2 个存储过程的代码。其中之一是使用动态 SQL，exec (@sql)以便我们知道为什么没有针对它的计划。但是另一台，也就是每分钟跑100次以上的，没有任何异常。唯一突出的是临时表是在超过 1000 行代码的中间创建的。它也确实调用了一堆子存储过程。
关于SQL Server 2008 中的计划缓存，我没有看到任何文字 >= 8k，但其中一个存储过程在调用另一个存储过程之前对批量插入有注释。但是批量插入没有出现在我正在查看的外部存储过程中。文章的“重新编译阈值”部分很有趣。我看到的临时表是大量的插入（可能导致数百万行）、一些更新和删除。因此临时表的大量数据更改。百万。