是否需要回收应用程序池才能刷新缓存的查询计划？答案

【问题标题】：Is it necessary to recycle app pool in order to refresh cached query plans?是否需要回收应用程序池才能刷新缓存的查询计划？
【发布时间】：2018-05-30 07:13:34
【问题描述】：

我不确定我问的问题是否准确，但如果你知道答案，那么你可能会明白我在问什么。

我更新了一个存储过程并在 dev 中进行了测试，没有问题。所以然后我更新了生产中的过程，它导致了错误。我花了一点时间弄清楚发生了什么，因为我所做的只是选择列表中的一个字段，从 i.Price 到 Price = coalesce(r.Price, i.Price)。最终我发现唯一的区别可能是 r.Price 是十进制值，而 i.Price 是货币值，因此该字段的返回类型已更改。

通常这对于 c# 代码应该无关紧要。无论哪种方式，DataReader 值都可以转换为十进制。但是我要修复错误所要做的就是重置应用程序池，然后它就可以工作了。我相信我也可以更新我的查询以转换为货币类型，这可能也可以。

我知道我之前遇到过几次此类问题，足以知道在 asp.net 和/或 sql 程序集的底层进行了某种缓存。

我的问题是，如何在不回收应用程序池的情况下刷新此缓存。还是只有这样？

【问题讨论】：

标签： asp.net sql-server-2012

【解决方案1】：

部署时究竟会发生什么：

ASP.NET 有一个称为卷影复制的功能，它可以在不卸载 AppDomain 的情况下更新应用程序域中使用的程序集。通常，这是必需的，因为公共语言运行时 (CLR) 将锁定程序集，因此您不能只是在其上复制新程序集。卷影复制意味着将原始程序集复制到临时位置。复制的程序集被锁定，原始程序集可以更新为新版本。

What is assembly interning?

发件人：

来自 MSDN：

ASP.NET 卷影复制功能允许更新应用程序域中使用的程序集，而无需卸载该 AppDomain（这是必要的，因为 CLR 会锁定正在使用的程序集）。这是通过将应用程序程序集复制到单独的位置（默认 CLR 确定的位置或用户指定的位置）并从该位置加载程序集来完成的。这允许在锁定卷影副本时更新原始程序集。默认情况下，ASP.NET 为 Bin 文件夹程序集打开此功能，以便在站点启动和运行时可以继续更新 DLL。

https://msdn.microsoft.com/en-us/magazine/hh882452.aspx

当发生以下情况时，应用程序池将自动回收：

应用程序的 BIN 目录中的任何修改

在任何配置文件中进行更改，例如 Web.config 或其他文件（如果您的应用程序中有任何特定的配置文件，例如在名为 App_Config 的目录中）。

在 APP_CODE 目录中的源代码文件中进行修改。这可能会更改任何源代码文件，或者在此目录中添加或删除文件。

在 Global.asax 文件中进行更改

在 Machine.config 文件中进行更改。

在 Web 应用程序的根目录中进行任何修改。这意味着动态创建文件/子目录会导致应用程序池回收。

App_WebReferences目录Web服务引用的修改。

修改根目录中任意目录的安全设置。（例如为每个人或任何其他特定用户或用户组指定读取安全权限。）

【讨论】：

嗯...为信息投票，但不确定你是否明白我的意思。我没有部署...只是通过 ssms 更新存储的过程。显然这样做不会回收应用程序池，我也不希望它这样做。但是，因为它已经被称为存储过程，我已经改变了它一直期望价格而不是十进制的货币价值，所以我必须回收应用程序池。我知道 c# 不在乎它是小数还是钱......对待两者都是一样的。但是有些东西在乎......我想知道如果可能的话，如何在不回收的情况下刷新那个“东西”。
我认为这类似于您在 SSMS 中并且您失去连接但随后将其恢复。您运行的下一个查询会给您一个错误，但是 ssms 足够聪明，可以自动尝试重新连接，并且您的下一个查询工作正常。实际上，我想这可以回答我的问题...如果出现问题，我可以编写尝试关闭并打开新连接的代码；好吧，除非它是池化的相同连接字符串，所以我必须弄清楚如何真正让它打开一个新连接，而不是返回相同的池化连接。或类似的东西。
哦，忘了完成我的想法：关键是如果 ssms 没有为您自动重新连接，那么您将不断收到与不使用的应用程序中发生的相同的错误这个逻辑。与我的场景有点不同，但有点相似，我认为我需要建立一个新的连接才能让它再次工作。