OPTION (RECOMPILE)쿼리에 추가 하면 0.5 초 안에 실행되는 반면, 생략하면 쿼리는 5 분 이상 걸리는 이상한 상황이 발생했습니다.
쿼리를 통해 쿼리 분석기 또는 내 C # 프로그램에서 쿼리를 실행하는 경우 SqlCommand.ExecuteReader()입니다. 전화 (또는 전화하지 않음) DBCC FREEPROCCACHE또는 DBCC dropcleanbuffers차이가 없습니다. 쿼리 결과는 항상 OPTION (RECOMPILE)5 분을 초과하지 않고 항상 즉시 반환 됩니다. 이 테스트를 위해 쿼리는 항상 동일한 매개 변수로 호출됩니다.
SQL Server 2008을 사용하고 있습니다.
SQL 작성에 상당히 익숙하지만 OPTION이전에는 쿼리에서 명령을 사용한 적이 없으며이 포럼의 게시물을 검색 할 때까지 계획 캐시의 전체 개념에 익숙하지 않았습니다. 게시물에서 내 이해 OPTION (RECOMPILE)는 비싼 작업 이라는 것입니다 . 분명히 쿼리에 대한 새로운 조회 전략을 만듭니다. 그렇다면 왜 생략하는 후속 쿼리 OPTION (RECOMPILE)가 너무 느립니까? 후속 쿼리에서 재 컴파일 힌트가 포함 된 이전 호출에서 계산 된 조회 전략을 사용하지 않아야합니까?
모든 단일 호출에서 재 컴파일 힌트를 요구하는 쿼리를 갖는 것이 매우 드문 일입니까?
초급 질문에 대해 죄송하지만 실제로 이것의 머리 나 꼬리를 만들 수는 없습니다.
업데이트 : 쿼리를 게시하라는 요청을 받았습니다 ...
select acctNo,min(date) earliestDate
from(
select acctNo,tradeDate as date
from datafeed_trans
where feedid=@feedID and feedDate=@feedDate
union
select acctNo,feedDate as date
from datafeed_money
where feedid=@feedID and feedDate=@feedDate
union
select acctNo,feedDate as date
from datafeed_jnl
where feedid=@feedID and feedDate=@feedDate
)t1
group by t1.acctNo
OPTION(RECOMPILE)Query Analyzer에서 테스트를 실행할 때 다음 행을 앞에 추가하십시오.
declare @feedID int
select @feedID=20
declare @feedDate datetime
select @feedDate='1/2/2009'내 C # 프로그램에서 호출하면 매개 변수가 SqlCommand.Parameters속성 을 통해 전달됩니다 .
이 논의의 목적으로, 매개 변수가 절대 변하지 않는다고 가정 할 수 있으므로 원인으로 최적이 아닌 매개 변수 냄새를 배제 할 수 있습니다.
X = @X OR @X IS NULL으로 X=@X하고 추구 수행 여기 참조 또는 윈도우 함수와 전망에 대해 더 아래 술어를 밀어
RECOMPILE. 어쨌든 실행 계획을 포착하고 차이점을 살펴보십시오.