특히 공통 하위 표현식 스풀을 사용하여 윈도우 집계 함수를 사용할 때 논리적 읽기가 너무 높은 이유는 무엇입니까?

윈도우 집계 함수의 논리적 읽기가 왜 그렇게 높은가요?

윈도우 집계 함수는 공통된 실행 계획에서 보고된 논리적 읽기가 높아질 수 있습니다. 특히 큰 테이블의 경우 하위 표현식 스풀입니다. 이 문서의 목적은 이러한 관찰의 이유를 설명하고 작업 테이블의 논리적 읽기 수를 이해하는 데 대한 통찰력을 제공하는 것입니다.

설명

작업 테이블의 논리적 읽기는 기존 읽기와 다르게 계산됩니다. 스풀 테이블. 작업 테이블에서 각 행 읽기는 하나의 "논리적 읽기"로 변환됩니다. 이는 "실제" 스풀 테이블에 대한 해시된 페이지 보고와 다릅니다.

이러한 방식으로 읽기 수를 계산하는 이유는 분석을 위해 더 의미 있는 정보를 제공한다는 것입니다. 작업 테이블에 대한 해시 페이지 추적은 이러한 구조의 내부 특성으로 인해 덜 유용합니다. 스풀링된 행 보고는 tempdb 리소스의 실제 활용도를 더 잘 반영합니다.

공식 파생

작업 테이블 논리적 읽기를 예측하기 위해 파생된 공식은 다음과 같습니다.

Worktable logical reads = 1 + (NumberOfRows * 2) + (NumberOfGroups * 4)

이 공식은 다음:

• 1: 작업 테이블에 대한 초기 데이터 로드를 나타냅니다.
• NumberOfRows * 2: 두 개의 보조 스풀( 행 반환 비용을 줄이기 위해 생성됨)은 완전히 읽혀집니다. 두 번.
• NumberOfGroups * 4: 기본 스풀은 아래 설명된 대로 행을 방출하여 고유 그룹 값의 개수(1 더하기)가 됩니다.

기본 스풀 행 방출

기본 스풀, 작업 행을 누적하고 집계 계산을 수행하면 다음과 같이 작동합니다.

• 입력에서 각 행을 읽어 작업 테이블에 씁니다.
• 새 그룹이 발견되면 다음을 내보냅니다. 새 그룹 파티션의 시작을 나타내는 중첩 루프 연산자에 대한 행.
• 각 그룹의 평균은 작업 테이블.
• 평균은 작업 테이블의 행과 결합됩니다.
• 다음 그룹을 준비하기 위해 작업 테이블이 잘립니다.
• 최종 그룹을 처리하기 위해 스풀은 더미 행.

추가 고려 사항

테스트 스크립트에서 동일한 프로세스를 복제하면 논리적 읽기 수가 11개로 줄어드는 것을 확인했습니다. 이러한 불일치는 다양한 환경에서 쿼리 프로세서가 사용하는 최적화 알고리즘으로 인해 발생합니다. 중첩 루프나 해시 조인이 사용되는 일반적인 경우에는 공식이 유효합니다.

결론

윈도우 집계 함수와 관련된 실행 계획을 정확하게 해석하려면 작업 테이블의 논리적 읽기에 대한 계산 차이를 이해하는 것이 필수적입니다. 제공된 공식은 작업 테이블의 논리적 읽기를 추정하는 유용한 방법을 제공하여 성능 분석 및 최적화 노력을 돕습니다.

위 내용은 특히 공통 하위 표현식 스풀을 사용하여 윈도우 집계 함수를 사용할 때 논리적 읽기가 너무 높은 이유는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!