저장 프로 시저의 쿼리 시간이 길어집니다. - EXEC vs SP_EXECUTESQL

Question

varbinary 열의 데이터에 대한 행 집합을 반환하는 저장 프로 시저를 사용하고 있습니다. 나는 내 인생을 위해서 exec과 대조적으로 sp_executesql을 사용할 때 쿼리 시간이 항상 같은 비율로 증가하는 이유를 파악할 수 없습니다.

sp_executesql 시간이

쿼리 이동 : 몇 분 동안 < 1 초, 1 초, 2 초, 4S, 8S, 24S (등), 결국, 문제는 "멀리 간다"까지를 쿼리는 항상 ~ 0.006s

입니다

exec의 검색어 시간은 항상 < 500ms입니다.

처음에는 이것이 Linq2Sql의 문제라고 생각했지만 Linq가 SQL Management Studio에서 생성 한 쿼리를 실행했을 때 동일한 결과가 나타났습니다. 여기

지속적으로 <은 500ms

USE [DerpDatabase] 
GO 

DECLARE @return_value int 

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

SELECT 'Return Value' = @return_value 

GO 

을 실행하는 코드 (심하게 검열)을 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 

끌려 가고 있지 않은지

주의 몸가요

다음은 1, 2, 4, 8, 24 등을 실행하는 코드입니다.

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_executesql 대 exec

은 결국 go 키워드없이 증가하는 쿼리 시간을 생성합니다. 쿼리를 캐시했을 때 잘 모르겠다 고 말할 수는 없다. go을 추가하려고했을 때?

Answer 1

이것은 매개 변수 스니핑 문제 일 수 있습니다. 가끔 프로 시저에 매개 변수를 전달할 때 SQL은 효율적으로 매개 변수를 사용하는 방법을 찾는 데 어려움을 겪습니다. 프로 시저에서 매개 변수를 로컬 변수로 설정 한 다음 where 절에서 로컬 변수를 사용하십시오.

Parameter Sniffing

Answer 2

필드를 파일 테이블에서 전용 테이블로 이동하여 문제를 해결했습니다. 지붕을 통과하는 쿼리 시간없이 파일 테이블과 메타 데이터 테이블간에 적절한 관계를 추가 할 수 없습니다.

우리가 쿼리를 저장 프로 시저로 실행할 때만 발생합니다. 필터에 대해 WHERE 절이있는 뷰와 동일한 쿼리를 수행 할 때 발생하는 문제는 아닙니다. 우리의 교훈은 SQL Server 2012에 우리의 SELECT 문에 포함되어 있지 않더라도 우리가 조인 한 테이블의 VARBINARY 필드가 쿼리에서 읽히는 버그 (?)가 있다는 것입니다.