실행 계획을 처음 살펴보면 표현식 1/0
이 Compute Scalar 연산자에 정의되어 있음을 보여줍니다 .
이제 실행 계획이 맨 왼쪽에서 실행되기 시작하지만 자식 반복자 에서 반복적으로 호출 Open
하고 GetRow
메서드를 반환하여 결과를 반환하지만 SQL Server 2005 이상에는 계산 이 종종 계산 스칼라에 의해서만 정의 되고 그 이후까지 평가가 지연 되는 최적화가 포함되어 있습니다. 작업 결과가 필요합니다 .
이 경우 표현식 결과 는 클라이언트로 리턴하기 위해 행을 어셈블 할 때만 필요합니다 (녹색 SELECT
아이콘 에서 발생한다고 생각할 수 있음 ). 이 논리에 따르면 지연된 평가는 계획이 리턴 행을 생성하지 않으므로 표현식이 평가되지 않음을 의미합니다. 포인트를 조금만 사용하기 위해 Clustered Index Seek 또는 Table Scan이 행을 반환하지 않으므로 클라이언트로 반환하기 위해 어셈블 할 행이 없습니다.
그러나 일부 표현은 다음과 같이 확인 할 수있다 별도의 최적화가 런타임 상수 등 쿼리 실행이 시작되기 전에 일단 평가는 . 이 경우 실행 계획 XML (왼쪽의 클러스터 된 인덱스 검색 계획, 오른쪽의 테이블 스캔 계획)에서이 문제가 발생했음을 나타냅니다.
기본 메커니즘 과이 블로그 게시물에서 성능 에 영향을 줄 수있는 방법에 대해 더 많이 썼습니다 . 여기에 제공된 정보를 사용하여 첫 번째 쿼리를 수정하여 실행이 시작되기 전에 두 표현식을 모두 평가하고 캐시 할 수 있습니다.
select 1/0 * CONVERT(integer, @@DBTS)
from #temp
where id = 1
select 1/0
from #temp2
where id = 1
이제 첫 번째 계획에는 상수 표현식 참조도 포함되어 있으며 두 쿼리 모두 오류 메시지를 생성합니다. 첫 번째 쿼리의 XML에는 다음이 포함됩니다.
추가 정보 : 계산 스칼라, 식 및 성능