相关疑难解决方法(0)

我知道这与参数嗅探有关,但我只是对以下示例的某些内容感到困惑,即使是一项能够很好地完成这么多复杂事情的技术.

我们中的许多人遇到了间歇性运行比平时慢几个数量级的存储过程,然后如果从过程中复制出sql并在单独的查询窗口中使用相同的参数值,则它会像往常一样快速运行.

我刚刚修改了这样的程序:

alter procedure p_MyProc
(
    @param1 int
) as -- do a complex query with @param1

对此:

alter procedure p_MyProc
(
    @param1 int
)
as

declare @param1Copy int;
set @param1Copy = @param1;

-- Do the query using @param1Copy

它从跑步一分钟后回到不到一秒钟,就像它通常运行一样.这种行为似乎完全随机.对于10个@param1输入中的9个,查询速度很快,无论它最终需要处理多少数据,或者结果设置多大.但是对于那10个中的1个,它只是迷失了.修复是用查询中的相同int替换int？

这没有道理.

[编辑]

@gbn链接到这个问题,详细说明了类似的问题:

已知问题？:SQL Server 2005存储过程无法使用参数完成

我犹豫着哭"Bug!" 因为这经常是一个警察,但这对我来说确实看起来像个错误.当我使用相同的输入运行我的存储过程的两个版本时,我看到相同的查询计划.唯一的区别是原始版本需要运行超过一分钟,而带有goofy参数复制的版本会立即运行.