통계, 실행 계획 및 '오름차순 키 문제'이해

통계, 실행 계획, 저장 프로 시저 실행 간의 관계를 (개념적으로) 더 잘 이해하려고합니다.

통계가 저장 프로 시저에 대한 실행 계획을 만들 때만 사용되고 실제 실행 컨텍스트에서 사용되지 않는다고 말하는 것이 맞습니까? 다시 말해서, 이것이 사실이라면, 계획이 만들어지고 적절하게 재사용되었다고 가정하면 "최신"통계가 얼마나 중요합니까?

나는 내가 읽은 기사 ( 통계, 행 추정 및 오름차순 날짜 열 ) 에 특히 동기를 부여 받았다.이 기사 는 여러 고객 데이터베이스에서 매일 직면하는 것과 매우 유사한 시나리오를 설명합니다.

특정 저장 프로 시저를 사용하여 정기적으로 쿼리하는 가장 큰 테이블 중 하나에 오름차순 날짜 / 시간 열이 있습니다.

하루에 십만 개의 행이 추가 될 때 실행 계획이 오래되지 않게하려면 어떻게해야합니까?

이 문제를 해결하기 위해 통계를 자주 업데이트하는 경우이 저장 프로 시저 쿼리에 OPTION (RECOMPILE) 힌트를 사용하는 것이 합리적입니까?

조언이나 권장 사항이 있으면 감사하겠습니다.

업데이트 : SQL Server 2012 (SP1)를 사용하고 있습니다.

통계가 저장 프로 시저에 대한 실행 계획을 만들 때만 사용되고 실제 실행 컨텍스트에서 사용되지 않는다고 말하는 것이 맞습니까?

아니요, 저장 프로 시저의 실행 계획이 캐시됩니다. 계획을 계속 유지할 수있는 충분한 메모리가 있다고 가정하면 다음 중 하나가 발생하지 않으면 변경되지 않습니다 ( SQL Server 문서의 실행 계획 캐싱 및 재사용 에서 강조).

• 쿼리에서 참조하는 테이블 또는 뷰의 변경 사항 (ALTER TABLE 및 ALTER VIEW).
• 단일 프로 시저를 변경하면 캐시에서 해당 프로 시저에 대한 모든 계획이 삭제됩니다 (ALTER PROCEDURE).
• 실행 계획에서 사용하는 인덱스로 변경합니다.
• UPDATE STATISTICS와 같은 명령문에서 명시 적으로 생성되거나 자동으로 생성 된 실행 계획에 사용되는 통계에 대한 업데이트입니다.
• 실행 계획에서 사용하는 인덱스를 삭제합니다.
• sp_recompile에 대한 명시 적 호출
• 키가 많이 변경됨 (쿼리가 참조하는 테이블을 수정하는 다른 사용자의 INSERT 또는 DELETE 문으로 생성됨)
• 트리거가있는 테이블의 경우, 삽입 또는 삭제 된 테이블의 행 수가 크게 증가합니다.
• WITH RECOMPILE 옵션을 사용하여 스토어드 프로 시저 실행

따라서 통계가 업데이트되면 캐시 된 계획에서 새 통계를 자동으로 고려하여 다시 컴파일합니다.

하루에 십만 개의 행이 추가 될 때 실행 계획이 오래되지 않게하려면 어떻게해야합니까?

한 가지 방법은 위에서 언급 한 것처럼 테이블에 많은 업데이트가있는 경우입니다. 수십만 개의 변경된 행이이 조건을 만족시킬 수 있습니다. 그러나 통계를 업데이트하여보다 세밀한 제어를 원하는 경우 SQL Server가 통계를 자동으로 생성 및 관리하도록하거나 직접 직접 수행 할 수 있습니다. SQL Server 자동 업데이트 및 자동 통계 생성 옵션 에서이 방법에 대한 자세한 정보를 찾을 수 있습니다 . 매주 인덱스를 다시 작성하면 계획도 업데이트됩니다. 통계를 너무 자주 업데이트하면 실제 성능 결과를 얻지 못할 수 있으므로 테스트를 수행하여 가장 유용한 것이 무엇인지 확인하십시오.

이 문제를 해결하기 위해 통계를 자주 업데이트하는 경우이 저장 프로 시저 쿼리에 OPTION (RECOMPILE) 힌트를 사용하는 것이 합리적입니까?

당신은하지 않습니다 필요 사용 RECOMPILE발췌 기반으로하기 때문에 새로운 통계를 사용할 때마다 실행 계획이 적절하게 업데이트되는 것을 볼 수 있습니다 위. 하루 종일 통계 업데이트 (정말 걱정되는 경우)로는 괜찮을 수 있지만 지금까지 말한 내용을 바탕으로 명시 적으로 필요하다고 생각하지 않습니다. 다시 한 번, 이것이 스토어드 프로 시저 성능에 어떤 영향을 미치는지 확인하고 그에 따라 계획합니다.

통계가 실행 계획을 만들 때만 사용된다고 말하는 것이 맞습니까?

아닙니다. 오래된 통계는 영향을받는 명령문의 최적 성 관련 재 컴파일 을 유발할 수 있습니다 .

정기적으로 쿼리하는 가장 큰 테이블 중 하나에 오름차순 날짜 / 시간 열이 있습니다.

술어 값이 해당 통계 히스토그램에 저장된 값 범위를 벗어나 (특히 위) 있기 때문에 최적이 아닌 실행 계획을 오름차순 키 문제점이라고 합니다. 통계 재 구축은 하나의 가능한 솔루션이지만 자원 집약적 일 수 있습니다. 대안은 다음과 같습니다.

• 추적 플래그 2389 및 2390 . 문제가되는 열을 선행 키로하는 인덱스가 있어야합니다. 파티션 된 테이블에서는 작동하지 않으며 원래 카디널리티 추정기가 사용되는 경우에만 SQL Server 2014에서 유효합니다. 통계 오브젝트가 정지 된 브랜드 인 경우 추적 플래그 4139 가 필요할 수도 있습니다.

• SQL Server 2014로 업그레이드하십시오. 새로운 카디널리티 추정기 는 평균 밀도 정보를 사용하여 히스토그램을 넘어 추정 하는 논리를 포함합니다. 일부 중요한 상황에서는 2389/2390 추적 플래그 보다 정확도 가 떨어질 수 있습니다 .

• 추적 플래그 2371을 사용 하여 대형 테이블에 대해 더 자주 자동 통계 업데이트를 사용하십시오 . 20 % + 500 명 이후에 변경이 추적 플래그 대신 갱신으로 만 SQRT(1000 * Table rows)수정이 요구된다. 업데이트가 여전히 자주 트리거되지 않을 수 있으므로이 방법은 앞에서 언급 한 것처럼 완벽한 솔루션이 아닙니다.

문제의 원인이 히스토그램을 넘어서는 술어 값을 기반으로 계획이 너무 자주 컴파일되지 않고 매개 변수 스니핑의 결과로 잘못된 계획을 캐싱하는 효과에 대한 자세한 내용은 다음을 고려할 수도 있습니다.

• 추적 플래그 4136을 사용하여 매개 변수 스니핑 사용 안함
• OPTIMIZE FOR (@parameter = value)알려진 대표 값에 대한 계획을 컴파일하는 데 사용
• OPTIMIZE FOR (@parameter UNKNOWN)평균 분포를 사용 하여 최적화
• 사용 OPTIMIZE FOR UNKNOWN(4136과 동일하지만 쿼리 당)
• OPTION (RECOMPILE)매번 컴파일하는 데 사용 하여 특정 값을 스니핑합니다. 대부분의 런타임 값이 히스토그램 내에 있으면 효과적 일 수 있습니다.

매개 변수 스니핑, 포함 및 재 컴파일 옵션에 대한 자세한 내용은 SQLperformance.com에 대한 내 기사 를 참조하십시오 .