在 sql server 存储过程中首次运行缓慢答案

【问题标题】：First run slowness in a sql server stored procedure在 sql server 存储过程中首次运行缓慢
【发布时间】：2011-06-27 02:56:00
【问题描述】：

我有一个存储过程，每天运行九次，就在午夜之后。它不是一个理想的存储过程，但你知道它是怎样的。任何计划都无法与现实接触。

这个存储过程通常需要大约一分钟的时间来运行，给它处理的数据量或花费时间。但是，在给定早晨的第一次运行中，有时会花费过多的时间，有时会比通常花费的时间长一个数量级（如果它完成的话）。如果我杀死它并重新启动它，它会正常运行。

我正在为此寻找一个优雅的解决方案 - 至少比我的第一个想法更优雅，即先运行一个额外的运行，它不会生成我使用的数据并且可以容忍失败。

以前有人见过这种行为吗？你是怎么解决的？

【问题讨论】：

【解决方案1】：

这可能是编译时间和冷数据缓存（缓冲池）。如果正常需要一分钟，那我想它也很厚实。

编译时间：执行计划在统计信息更新时失效。如果您有批量处理或通宵维护，您可能会遇到此问题

冷缓存：数据/索引页面必须从磁盘进入内存。

要缓解这些问题：

我们有时也会遇到同样的问题，尤其是在开发工具箱上，例如我们的网站会超时。我们只需再次点击...

【讨论】：

最终我通过更新存储过程以使用动态搜索条件解决了这个问题。（sommarskog.se/dyn-search-2005.html 是经典指南）此更改将所有运行的处理时间缩短到亚秒级执行，无论是第一次还是其他。
@quillbreaker：很好……你有结果了。无论如何，该网站值得一读
第一次运行花了很长时间，这不仅仅是编译问题，除非他们用图形计算器替换了我们的 SQL Server 硬件。

【解决方案2】：

为了提供解决方案，首先要做的是调查原因。可能有许多问题会表现为您描述的症状。始终按照调查方法（如 Waits And Queues）开始排查性能问题。这将揭示为什么程序在第一次运行时很慢。可能的罪魁祸首：

根据您发现的问题，会有适当的解决方案。

您应该不做的一件事是盲目地更改设置并希望问题消失，却不知道出了什么问题。

【讨论】：

【解决方案3】：

在 proc 每天第一次运行的同时还发生了什么？是否会从其他进程（备份、统计更新、其他计划作业）获得锁？

【讨论】：

【解决方案4】：

存储过程存储在 sqlserver 中。

如果您使用 DBCC FREEPROCCACHE，它将重新编译 sql 语句。

如果您的服务器正在重新启动（比如每晚或每周），它可能会清除其缓存，这会导致查询在第一次尝试时运行缓慢。

您可以通过运行上述命令并运行查询来测试它是否会发生同样的事情......如果是这样，我会说您的缓存正在被清除。

【讨论】：

【解决方案5】：

数据库的 AUTO_UPDATE_STATISTICS 或 AUTO_UPDATE_STATISTICS_ASYNC 是否开启？可能是第一次运行通知需要更新统计信息并这样做。在前一个设置选项中，它等待统计信息更新完成，而对于后者，它不等待统计信息更新，但可能会选择次优计划，从而导致性能不佳。

【讨论】：