我有一个存储过程，每天运行九次，午夜过后。这不是一个理想的存储过程，但你知道它是如何。没有计划能够与现实保持联系。sql server存储过程中的首次运行缓慢
该存储过程通常需要大约一分钟的时间运行，给予或花费其处理的数据量的时间。但是，对于某个早晨的第一次运行，有时会花费过多的时间，有时甚至比通常花费的时间长得多（如果它完成的话）。如果我杀了它并重新启动它，它会正常运行。
我正在寻找一个优雅的解决方案 - 至少比我的第一个想法更优雅，那就是先打一个额外的跑步，先不要生成我使用的数据，并且可以容忍其中的失败。
有没有人见过这种行为？你是如何解决它的？
它可能是编译时和冷数据缓存（缓冲池）。如果通常需要一分钟，那么我认为它也很笨重。
编译时间：执行计划在统计更新时失效。如果您有批量处理或过夜维护，您可能会遇到这种情况：您需要将数据/索引页面从磁盘传输到内存中。
为了减轻这些：
我们有同样的问题，有时，特别是在发展框，以我们的网站超时为例。我们只需再次点击...
存储过程分散在sqlserver中。
如果使用DBCC FREEPROCCACHE它会重新编译sql语句。
如果您的服务器正在重新启动（例如每晚或每周），可能会清除缓存，这会导致查询在第一次尝试时运行缓慢。
你可以通过运行上述命令并运行查询来查看是否发生了同样的事情......如果是的话我会说你的缓存已经被清除了。
为了提供解决方案，首先要做的是调查原因。可能会出现许多问题，这些问题会显示为您描述的症状。 总是通过遵循调查方法开始排除性能问题，如Waits And Queues。这将揭示为什么是第一次运行缓慢的过程。罪魁：
取决于你发现了什么作为的问题，将是一个合适的解决方案。
你应该做的一件事不是做的是盲目地改变设置，希望问题消失，不要理解错误。
对于数据库，AUTO_UPDATE_STATISTICS或AUTO_UPDATE_STATISTICS_ASYNC是？可能是第一次运行注意到统计数据需要更新并且这样做。在前一个选项中，它等待状态更新完成，对于后者，它不会等待状态更新，但可能选择次优计划，从而导致性能不佳。
在proc每天第一次运行的同时还会发生什么？它可能是从其他进程（备份，统计信息更新，其他预定作业）获取锁吗？
您是否使用任何动态SQL或非sargable参数？ – Matthew 2011-02-14 18:33:50
并且是否有任何理由缓存存储过程执行计划一夜之间会丢失？ – Rup 2011-02-14 18:34:39
@Rup：统计数据更新为 – gbn 2011-02-14 18:39:33