실행 계획과 STATISTICS IO 순서

SQL Server 그래픽 실행 계획은 오른쪽에서 왼쪽으로, 위에서 아래로 읽습니다. 에 의해 생성 된 출력에 의미있는 순서가 SET STATISTICS IO ON있습니까?

다음 쿼리 :

SET STATISTICS IO ON;

SELECT  *
FROM    Sales.SalesOrderHeader AS soh
        JOIN Sales.SalesOrderDetail AS sod ON soh.SalesOrderID = sod.SalesOrderID
        JOIN Production.Product AS p ON sod.ProductID = p.ProductID;

이 계획을 생성합니다.

그리고이 STATISTICS IO출력 :

Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'SalesOrderDetail'. Scan count 1, logical reads 1246, physical reads 3, read-ahead reads 1277, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'SalesOrderHeader'. Scan count 1, logical reads 689, physical reads 1, read-ahead reads 685, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Product'. Scan count 1, logical reads 15, physical reads 1, read-ahead reads 14, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

그래서 나는 반복한다 : 무엇을 주는가? STATISTICS IO출력 순서가 의미 가 있거나 임의의 순서가 사용됩니까?

다양한 쿼리로 처음 놀았을 때 전혀 패턴이 없었지만 더주의를 기울이면 일련 계획에 대해 예측 가능한 것으로 보입니다. 나는에 결국 KB314648 @AustinZellner 언급되는 :

각 SQL Server 연결에는 연결 별 상태 정보를 유지 관리하는 관련 프로세스 상태 구조 (PSS)가 있습니다. sysprocesses 시스템 테이블의 각 고유 SPID (서버 프로세스 ID)는 다른 PSS를 나타내며 sysprocesses 가상 테이블의 정보는이 상태 정보에 대한 "보기"입니다.

그리고 귀하의 질문과 관련된 섹션 :

연결에 대해 STATISTICS IO가 활성화 된 경우 SQL Server는 쿼리 실행 중에 배열을 할당하여 테이블별로 IO 정보를 추적합니다. SQL Server는 쿼리를 처리 할 때 해당 논리적 IO 요청이 물리적 IO를 발생했는지 여부와 함께이 배열의 해당 테이블 항목에 페이지에 대한 각 논리적 요청을 기록합니다. SQL Server는 쿼리 끝에 오류 메시지 3615로 정보를 반환합니다.

관찰 된 동작은 IO가 생성 된 순서대로 배열에 항목이 작성됨을 나타냅니다. 기본적으로 실제 연산자의 GetNext () 결과입니다. 통계 출력의 마지막 항목은 IO가 기록 된 첫 번째 테이블이고 첫 번째 항목은 마지막 테이블입니다. 어떤 병렬 작업이 먼저 예약되는지에 대한 보장이 없으므로 병렬 계획의 순서는 예측할 수 없다고 추측합니다.

계획에서 데이터 읽기 액세스의 반대 순서 인 것처럼 보입니다. 계획은 먼저 제품 테이블에서 읽어 해시 테이블 (작업 테이블)을 작성합니다. SalesOrderHeader에서 읽은 후 병합 조인 연산자와 결합하여 SalesOrderDetail을 형성합니다. 그런 다음 작업 테이블을 마지막부터 읽어 원래 제품 행과 병합 조인의 행을 해시 일치시킵니다. 이것이 통계 출력에 나열된 순서와 정확히 반대입니다.

그러나 이것을 지정하는 문서는 알지 못합니다. 어떤 순서로 테이블 액세스가 발생했는지 확인하려면 실행 계획을 읽으십시오.

나는 행정보다 프로그래밍을 더 많이 할 때부터 질서가 있다고 생각했다. 나는 몇 가지 실행 계획을 겪고 내 믿음을 두 번 확인했습니다.

다음은 내가 보는 것입니다.

여러 단계의 쿼리 (예 : 많은 저장 프로 시저)에서 순서는 쿼리가 실행되는 물리적 순서를 반영합니다.

특정 쿼리의 경우 통계 IO는 오른쪽에서 시작하여 왼쪽으로 작업하는 통계를보고하여 실행 계획을 반영하는 것처럼 보입니다.

아마도 이것은 다른 것보다 더 많은 관찰 일 것입니다.

따라서 통계 결과는 런타임에 실제로 발생하는 상황에 대해 훨씬 더 많은 통찰력을 제공한다고 생각합니다. 캐시 대신 디스크에서 읽을 필요가 있고 계정의 권한에 의해 영향을 받기 때문입니다. 쿼리가 실행되고 있습니다. 통계 리턴에서 테이블의 위치는 프로파일 러가 고려한 것 이외의 다른 요인에 의해 영향을받습니다.

다음은 통찰력과 몇 가지 예를 제공하는 KB 문서입니다. http://support.microsoft.com/kb/314648