"예상 실행 횟수"가 비정상적으로 증가했습니다.

예상치 못한 오류가 발생하여 더 빠른 쿼리 대신 느린 쿼리 계획을 선택하는 경우가 있습니다. 그러나 잘못된 추정값의 출처를 파악할 수 없습니다. 다음은 인덱스 탐색에 대한 예상 비용이 123이므로 선택되지 않은 빠른 계획입니다. 실제 비용은 실제 및 예상 실행 횟수의 차이에서 볼 수있는 것만 큼 높지 않습니다. 내 이해는 실행 횟수가 중첩 루프의 위쪽에서 행 수에 의해 결정된다는 것입니다. 보시다시피 예상 행 수는 4878이며 실제와 거의 같습니다. 그러나 최하위 입력에 대한 예상 실행 횟수는 61110이며, 이는 근사치입니다. FWIW, 전체 스캔으로 모든 테이블에 대한 통계를 업데이트했으며, 1.22 예상 행 수가 정확합니다 (각 실행에 대해)."예상 실행 횟수"가 비정상적으로 증가했습니다.

61110 번호는 어디에서 왔으며이를 해결할 수있는 방법은 있습니까?

쿼리는 다음과 같습니다 : 그것은 문제의 특정 인스턴스를 밝혀

SELECT 
     Top.Pk 
    FROM 
     Top 
     LEFT JOIN Bottom ON Bottom.Fk = Top.Pk 
    WHERE 
     Top.Date < GETUTCDATE() 
     AND Bottom.Fk IS NULL

출처

2016-11-07 James Brantly

내가 언급 한 것을 잊어 버렸습니다. 중요한 테이블은 중요한 경우 인덱스 된보기입니다. –

실제 쿼리 및 테이블에 대한 자세한 내용을 제공해야합니다. 통계는 카디널리티 추정의 한 측면 일뿐입니다. 다음 목록에 귀하의 검색 및 참여 조건이 실제로 무엇입니까. 공통된 문제점은 옵티마이 저가 실제 테이블 내용과 상관 될 수없는 조인 조건을 갖는 것입니다. 따라서 일치하는 행 수의 테이블 크기만을 기준으로 따로 따로 계산하십시오. 또 다른 문제점은 모든 최적화 프로그램이 알고있는 특정 일치 항목에 실제로 60.000 개의 결과 행이있을 수있는 매우 균일하지 않은 콘텐츠가있는 테이블입니다. –

이 경우 GUID에 가입합니다. 상위 테이블의 PK가 맨 아래의 FK입니다. 그것은 추구의 유일한 술어입니다. 동질성에 관해서는, 그것이 통계의 요점이라고 생각했습니다. 그럼에도 불구하고 예상 행 수는 정확합니다 (특정 일치 항목에 60,000 개의 결과 행이 없으며 1.22가 있음). 이슈는 예상 실행 횟수이며, 스크린 샷에서 중첩 된 루프의 설명에 따라 최상위 입력에 의해 결정됩니다. –

나는 아직 완전히 실행 계획이 우리를 여기에서 보여주는 이해하지 않지만 수 인덱싱 된 뷰에 WITH (NOEXPAND)을 지정하여 수정해야합니다. 인덱스 된 뷰 (인덱스가 이미 실행 계획에서 수행 중이라고 생각했지만 분명히 그렇지 않은 인덱스)를 고려하도록 옵티마이 저가 강제 수행해야합니다.

출처

2016-11-07 16:22:18

"예상 실행 횟수"가 비정상적으로 증가했습니다.

답변

관련 문제