相关疑难解决方法(0)

不久之前,我有一个查询,我为我的一个用户运行了很多.它仍然在进化和调整,但最终它稳定并且运行得非常快,所以我们从中创建了一个存储过程.

到目前为止,这是正常的.

但是,存储过程很慢.查询和proc之间没有实质性差异,但速度变化很大.

[后台,我们正在运行SQL Server 2005.]

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

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

那么,是什么给出的？有人可以解释参数欺骗吗？

奖金积分

• 强调如何避免它
• 建议如何识别可能的原因
• 讨论替代策略,例如统计数据,指数,关键,以减轻这种情况

我在SQL(变量名称混淆)中获得了以下查询,该查询试图获得值(Ch,Wa,Bu,Hi),从而得到Pi条目的最大数量(cnt).

select top 1 Pi.Ch, Pi.Wa, Pi.Bu, Pi.Hi, COUNT(1) as cnt 
from Product, Si, Pi
where Product.Id = Si.ProductId
and Si.Id = Pi.SiId
and Product.Code = @CodeParameter
group by Pi.Ch, Pi.Wa, Pi.Bu, Pi.Hi
order by cnt desc

它在我们的生产数据库的SQL管理工作室中立即运行.我已经在C#LINQ和Entity Framework中成功编写了一些代码,但代码运行的方式都是8到10秒.一次尝试是以下代码(在没有打印的情况下执行此操作,因为一次调用会产生相同的性能结果):

using(var context = new MyEntities()){
    var query = context.Products
        .Where(p => p.Code == codeFromFunctionArgument)
        .Join(context.Sis, p => p.Id, s => s.ProductId, (p, s) => new { sId = s.Id })
        .Join(context.Pis, ps => ps.sId, pi => pi.SiId, (ps, pi) => new …

我用一个非常基本的 EF 语句超时。我只是从带有 Entity.Title.StartsWith("test") 和 .Take(25) 的单个表中进行选择。当我为不返回任何结果的搜索运行此程序时，我会超时。

如果我分析并抓取 sql 语句，它看起来不错，如果我在 Management Studio 中运行该 sql，它会在几分之一秒内运行！

为什么相同的查询会在 Management Studio 中运行亚秒级并在由 EF 生成并从 Asp.Net 应用程序调用时超时？