我们的应用程序使用.net sql驱动程序，查询最终在profiler中看起来像这样：
sp_executesql N'query where @param = ?, and param2 = ?', param, param2, param3, etc 当从Profiler复制并粘贴查询到SQL Serverpipe理工作室时，查询将在不到一分钟的时间内运行，从应用程序执行15到20分钟。
据我所知他们都使用相同的执行计划，所以我不知道会有什么不同。
为了增加奇怪性，我们还有一个基本上是生产服务器副本的testingsql服务器。 在我们的testing环境中，使用相同的代码和大部分相同的数据（生产date过了几天），查询在我们的应用程序以及sql server management studio中运行不到一分钟。 探测器再一次捕捉到所有这些执行计划。
我发现的唯一的事情使查询运行正确的是在数据库上运行sp_updatestats，我们每天早上5:00运行。 奇怪的是到凌晨7点，查询仍然会再次缓慢运行。 如果我再次运行sp_updatestats，查询将在一分钟内完成。 再一次，所有的执行计划看起来都是一样的。
我肯定错过了什么。 有任何想法吗？
您的查询是否涉及一个具有升序date时间或date时间2列的表，其中一个参数是date时间或date时间2，通常查找最近的值？
在更新统计信息之后，您对行为的评论意味着您遇到了Gail Shaw在这里描述的频繁过时统计信息的问题： http : //sqlserverpedia.com/blog/sql-server-bloggers/statistics-row-estimations-and-the -ascending最新列/
盖尔提到，最直接的解决办法是更频繁地更新统计数据。 理想情况下，将更频繁的更新定位到只需要它们的统计信息 – 请参阅更新统计信息 。
在表格很大的情况下，根据表格大小，更新和读取模式，过滤的索引也可能是有用的。
目前在尝试升级我的SQL技能的过程中，所以采取这一粒盐。 但也许这是一个参数嗅探问题？
参数嗅探是SQL Server通过使用第一次执行存储过程时传递的调用参数为存储过程创build最佳计划的过程。 “第一次”，我的意思是每当SQL Server被迫编译或重新编译存储过程，因为它不在过程caching中。 随后每次调用具有相同参数的同一商店过程也将获得最佳计划，而具有不同参数值的调用可能并不总是最佳计划。
– http://www.simple-talk.com/sql/t-sql-programming/parameter-sniffing/
正如我在我的免责声明中所说的，我在这里有很多东西需要学习，但是如果我正确地理解了这种情况，那么我认为如果您将OPTION RECOMPILE重新传递给查询并且问题消失，则可能是您的问题。