不久之前,我有一个查询,我为我的一个用户运行了很多.它仍然在进化和调整,但最终它稳定并且运行得非常快,所以我们从中创建了一个存储过程.
到目前为止,这是正常的.
但是,存储过程很慢.查询和proc之间没有实质性差异,但速度变化很大.
[后台,我们正在运行SQL Server 2005.]
友好的本地DBA(不再在这里工作)看了一下存储过程并说"参数欺骗!" (编辑:虽然它似乎也可能被称为'参数嗅探',这可能解释了当我试图搜索它时谷歌的点击率很低.)
我们将一些存储过程抽象到第二个存储过程,将对这个新内部过程的调用包装到预先存在的外部过程中,称为外层过程,嘿,它与原始查询一样快.
那么,是什么给出的？有人可以解释参数欺骗吗？
奖金积分
我已经阅读了SQL Server 2008 OPTIMIZE FOR UNKNOWN查询提示.我明白它是如何工作的.
不过,我有个问题在那里,并在使用它.它不能在UDF中指定.它可以在存储过程中指定.但是,这篇 MSDN博客文章陈述如下:
4.将查询移入存储过程可以将其置于单独的过程上下文中,并且可以是优化器可以看到该值的好方法(注意:这也适用于SQL 2000)
在我看来,传递给存储过程的任何参数都将被"嗅探",从而帮助SQL Server编译最佳执行计划.这意味着将重新访问/重新编译缓存的计划(不确定该机制).然而,这是令人困惑的,因为它否定了OPTIMIZE FOR UNKNOWN的全部需求.
关于查询提示的MSDN文章没有涵盖我的问题.
有人可以为我解答这个问题,理想情况下是指向微软的一些东西来解决这个问题.谢谢.
我有一个查询,其中有一个使用许多局部变量构建的where子句,但这很慢.下面是一个粗略的例子,因为我目前无法访问查询:
declare @a varchar(50), @b varchar(50), @c varchar(50)
set @a = '%'
set @b = 'foo'
set @c = '%bar'
我的where子句是什么样的
where a = @a and b = @b and c =@c
这需要大约1分钟才能运行.但是,如果我直接引用where子句中的值,例如:
where a = '%' and b = 'foo' and '%bar'
大约需要5秒钟.
所以我的问题是,有没有更好的方法来构建我的where子句？需要注意的一件重要事情.where子句中使用了大约10个局部变量,但大多数都设置为默认值%
提前致谢