为了账号安全,请及时绑定邮箱和手机立即绑定

请问SQL Server中的参数嗅探(或欺骗)

/ 猿问

请问SQL Server中的参数嗅探(或欺骗)

吃鸡游戏 2019-10-22 17:12:47

SQL Server中的参数嗅探(或欺骗)

不久前,我有一个查询,我为我的一个用户运行了相当多的查询。它仍然在进化和调整,但最终它的建立和运行速度相当快,所以我们用它创建了一个存储过程。

到目前为止还很正常。

然而,存储过程是缓慢的。查询和proc之间没有实质区别,但速度变化很大。

[背景,我们正在运行SQLServer 2005。]

一个友好的本地DBA(不再在这里工作)看了一下存储过程,说:“参数欺骗!”编辑:虽然它似乎也可能被称为“参数嗅探”,但这或许可以解释为什么当我试图搜索它时,谷歌点击率很低。)

我们将一些存储过程抽象为第二个存储过程,将对这个新的内部过程的调用封装到先前存在的外部过程中,称为外部过程,并且,嘿,presto,它与原始查询一样快。

那么,是什么原因呢?有人能解释参数欺骗吗?

奖金信贷

  • 突出强调如何避免
  • 建议如何识别可能的原因
  • 讨论其他策略,例如统计数据、索引、键,以缓解这种情况。


查看完整描述

3 回答

?
拉丁的传说

FYI-当您使用SQL 2005并使用参数存储Procs时,您需要知道其他一些事情。

SQLServer将使用的第一个参数编译存储的proc的执行计划。所以如果你运行这个:

usp_QueryMyDataByState 'Rhode Island'

执行计划对一个小州的数据最有效。但如果有人转身跑:

usp_QueryMyDataByState 'Texas'

为罗得岛州大小的数据设计的执行计划可能没有得克萨斯州大小的数据那么有效。当服务器重新启动时,这可能会产生令人惊讶的结果,因为新生成的执行计划将针对首先使用的任何参数-不一定是最好的参数。除非有很大的理由去做,否则这个计划是不会被重新编译的,就像重建统计数据一样。

这就是查询计划出现的地方,SQLServer 2008提供了许多新特性,帮助DBA将特定的查询计划长期固定在适当的位置,而不管首先调用什么参数。

我担心的是,当您重新构建存储的proc时,您强制执行计划重新编译。您使用您最喜欢的参数调用它,当然它是快速的-但是问题可能不是存储的proc。可能是存储的proc在某个时候用一组不寻常的参数重新编译,从而导致查询计划效率低下。您可能没有修复任何东西,下次服务器重新启动或查询计划重新编译时,您可能会遇到同样的问题。



查看完整回答
反对 回复 2019-10-23
?
qq_笑_17

是的,我认为您的意思是参数嗅探,这是SQL Server优化器用来试图计算参数值/范围的一种技术,这样它就可以为查询选择最佳的执行计划。在某些情况下,SQLServer在参数嗅探方面做得很差&没有为查询选择最佳的执行计划。

我相信这篇博客文章http:/blogs.msdn.com/queryoptTeam/Archive/2006/03/31/565991.aspx有一个很好的解释。

在您的示例中,DBA似乎选择了选项4将查询移动到另一个sproc,以单独的过程上下文。

你也可以用重编译在原始sproc或使用优化为参数的选项。



查看完整回答
反对 回复 2019-10-23
?
45度呼吸

加快速度的一个简单方法是在sproc开始时将输入参数重新分配到本地参数。

CREATE PROCEDURE uspParameterSniffingAvoidance    @SniffedFormalParameter intASBEGIN

    DECLARE @SniffAvoidingLocalParameter int    SET @SniffAvoidingLocalParameter = @SniffedFormalParameter   
     --Work w/ @SniffAvoidingLocalParameter in sproc body 
    -- ...



查看完整回答
反对 回复 2019-10-23

添加回答

回复

举报

0/150
提交
取消
意见反馈 帮助中心 APP下载
官方微信