通过.net sql驱动程序与运行的查询截然不同

Question

我们的应用程序使用.net sql驱动程序，查询在分析器中看起来类似于这样：

sp_executesql N'query where @param = ?, and param2 = ?', param, param2, param3, etc

当将查询从Profiler复制并粘贴到sql服务器管理演播室时，查询将在不到一分钟的时间内运行，而从应用程序执行的时间将不到15-20分钟。

据我所知，他们都在使用相同的执行计划，所以我不确定什么是不同的。

更奇怪的是，我们还有一个测试sql服务器，它基本上是生产服务器的副本。在我们的测试环境中，使用相同的代码和大多数相同的数据(从生产开始的几天后)，查询在我们的应用程序和sql server管理演播室中运行不到一分钟。再一次，分析器正在捕获所有它们的完全相同的执行计划。

我所发现的使查询正确运行的唯一方法是在数据库上运行sp_updatestats，我们每天早上5:00运行该数据库奇怪的是，到早上7点，查询仍将缓慢运行。如果我再次运行sp_updatestats，查询将在不到一分钟内完成。再一次，所有的执行计划看起来都一样。

我一定是漏掉了什么。有什么想法吗？

Answer 1

您的查询是否涉及具有升序datetime或datetime2列的表，其中一个参数是datetime或datetime2，通常是查找最近的值？

您对更新统计数据后的行为的评论表明，Gail在这里描述的经常过时的统计数据存在问题：http://sqlserverpedia.com/blog/sql-server-bloggers/statistics-row-estimations-and-the-ascending-date-column/

正如Gail所提到的，最直接的解决方案是更频繁地更新统计数据。理想的目标是那些只需要这些统计信息的更频繁的更新--参见更新统计。

对于非常大的表，筛选索引也可能有用，这取决于表的大小以及更新和读取模式。

Answer 2

目前正在尝试升级我的SQL技能，因此请稍加考虑。但也许这是一个参数嗅探问题？：

参数嗅探是Server使用第一次执行存储过程时传递的调用参数为存储过程创建最佳计划的过程。所谓“第一次”，实际上是指每当SQL Server被迫编译或重新编译存储过程时，因为它不在过程缓存中。对具有相同参数的相同存储过程的每个后续调用也将得到最优计划，而具有不同参数值的调用可能并不总是得到最优计划。

-- http://www.simple-talk.com/sql/t-sql-programming/parameter-sniffing/

正如我在免责声明中所说的，我在这里有很多需要学习的地方，但是如果我正确地理解了这一点--如果是这样的话--我认为如果您将OPTION RECOMPILE传递给查询并且问题消失了，这可能是您的问题。