存储过程的查询时间越来越长。 - EXEC vs SP_EXECUTESQL

时间:2012-08-16 15:53:30

标签: sql sql-server linq-to-sql stored-procedures

我正在使用存储过程返回一组关于varbinary列中数据的行。在我的生活中,我不能弄清楚为什么当我使用sp_executesql而不是exec时,查询时间总是以相同的速率增加。

sp_executesql次查询:< 1s,1s,2s,4s,8s,24s(等),直到最终问题“消失”几分钟,查询为总是 ~0.006s

exec的查询时间始终<500毫秒。

起初,我认为这是Linq2Sql的问题,但是当我们运行Linq在SQL Management Studio中生成的查询时,我们得到了相同的结果。

这是sproc的主体(严格审查)

请注意,varbinary列未被提取

select DF.FileID, 
       DF.DerpFkGuid, 
       DF.DerpName, 
       DF.[FileName],
       DF.FileSize as 'FileSizeBytes', 
       ISNULL(DFA.File_Size_Bytes_String,'Unknown') as 'FileSizeFriendly', 
       CONVERT(nvarchar(30),DF.FoundDate,120) as 'FileDateUploaded', 
       CONVERT(nvarchar(30),DF.FileDateCreated,120) as 'FileDateCreated',
       CONVERT(nvarchar(30),DF.FileDateLastModified,120) as 'FileDateModified',
       CASE WHEN ISNULL(dfa.Derp_ID,'00000000-0000-0000-0000-000000000000')='00000000-0000-0000-0000-000000000000' THEN 0 ELSE 1 END as 'AttachedToDerp', 
       ISNULL(dfa.Derp_ID,'{00000000-0000-0000-0000-000000000000}') as 'Derp_ID'
from DerpFiles DF   
inner join DFDerpDerp DFdd      on DFdd.DerpName = DF.DerpName
left outer join Derp_Files_Attachments dfa      on dfa.FileID =  DF.FileID
where WR.UserName = @UserName and DF.DuplicateFileDetected=0

以下是一致运行的代码&lt; 500毫秒

USE [DerpDatabase]
GO

DECLARE @return_value int

EXEC    @return_value = [dbo].[DerpSproc]
        @UserName = N'derp',
        @DomainName = N'derp'

SELECT  'Return Value' = @return_value

GO

以下是运行1s,2s,4s,8s,24s等的代码

declare @p5 int
set @p5=0
exec sp_executesql N'EXEC   @RETURN_VALUE = [dbo].[DerpSproc] 
                            @UserName = @p0, 
                            @DomainName = @p1',                         
                            N'@p0 nvarchar(4000),
                            @p1 nvarchar(4000),
                            @RETURN_VALUE int output',
                            @p0=N'derp',
                            @p1=N'derp',
                            @RETURN_VALUE=@p5 output
select @p5

据我所知,调用sprocs的两种方式基本相同。唯一的区别是sp_executesqlexec

exec似乎也会产生相同的增加查询时间,而最后没有go关键字。我无法确定,因为当我尝试添加go时,我不知道查询是否恰好发生了缓存?

2 个答案:

答案 0 :(得分:1)

这可能是一个参数嗅探问题。有时,当您将参数传递给过程时,SQL很难确定如何有效地使用它们。尝试在过程中将参数设置为局部变量,然后在where子句中使用局部变量。

Parameter Sniffing

答案 1 :(得分:0)

我们通过将VARBINARY字段从files表移动到自己的专用表来解决了我们的问题。我们无法在文件表和元数据表之间添加适当的关系,而无需查询时间。

仅当我们将查询作为存储过程执行时才会发生这种情况。当我们对具有WHERE子句的视图执行与我们的过滤器完全相同的查询时,就不会发生这种情况。我们受过温和教育的理论是SQL Server 2012有一个错误(?)导致我们加入的表中的VARBINARY字段在我们的查询中被读取,即使它没有包含在我们的SELECT语句中