首先在sql server存储过程中运行缓慢

Question

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

此存储过程通常需要大约一分钟才能运行，为其处理的数据量提供或花费时间。然而，在给定早晨的第一次运行中，有时它将花费过多的时间，有时比​​通常花费的时间长一个数量级（如果它完全结束）。如果我杀了它并再次启动它，它会正常运行。

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

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

Answer 1

可能是编译时和冷数据缓存（缓冲池）。如果通常需要一分钟，那么我猜它也很粗糙。

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

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

要缓解这些：

• 虚拟跑步（如上所述）
• 更快的IO或更多RAM
• plan guides

我们有同样的问题，有时候，特别是在开发框上，例如我们的网站超时。我们再点击一下......

Answer 2

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

• 冷缓存
• 使用其他进程对某些资源（锁？）进行争用
• 参数嗅探导致计划错误

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

你应该不做的一件事是盲目地改变设置并希望问题消失，而不必理解错误。

Answer 3

在每天第一次进行proc的同时还发生了什么？是否可以从其他进程（备份，统计信息更新，其他预定作业）获取锁定？

Answer 4

存储过程在sqlserver中加载。

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

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

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

Answer 5

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