통계는 최신이지만 예상치가 잘못되었습니다


12

내가 할 때 dbcc show_statistics ('Reports_Documents', PK_Reports_Documents)나는 보고서 ID 18698에 대한 다음과 같은 결과를 얻을 :

여기에 이미지 설명을 입력하십시오

이 쿼리의 경우 :

SELECT * 
FROM Reports_Documents 
WHERE ReportID = 18698 option (recompile)

Clustered Index Seek를 PK_Reports_Documents예상대로 수행 하는 쿼리 계획이 있습니다.

그러나 나를 괴롭히는 것은 예상 행 수에 대한 잘못된 값입니다.

여기에 이미지 설명을 입력하십시오

에 따르면 :

샘플 쿼리 WHERE 절 값이 히스토그램 RANGE_HI_KEY 값과 같으면 SQL Server는 히스토그램의 EQ_ROWS 열을 사용하여 동일한 행 수를 결정합니다.

이것은 또한 내가 기대하는 방식이지만 실제로는 그렇지 않은 것 같습니다. 나는 또한 RANGE_HI_KEY히스토그램에 존재 show_statistics하고 경험 했던 다른 값들을 시도했다 . 필자의 경우이 문제로 인해 일부 쿼리에서 매우 최적화되지 않은 실행 계획을 사용하여 몇 분의 실행 시간이 발생하는 반면 쿼리 힌트로 1 초 안에 실행할 수 있습니다.

전체적으로 : 누군가 EQ_ROWS히스토그램의 결과가 예상 행 수에 사용되지 않는 이유 와 잘못된 추정치의 출처를 설명 할 수 있습니까 ?

좀 더 도움이 될만한 정보 :

  • 통계 자동 작성이 켜져 있고 모든 통계가 최신입니다.
  • 쿼리중인 테이블에는 약 8 천만 개의 행이 있습니다.
  • PK_Reports_Documents조합 PK가 이루어진된다 ReportID INTDocumentID CHAR(8)

이 쿼리는 총 5 개의 다른 통계 개체를로드하는 것으로 보이며,이 개체에는 모두 ReportID테이블의 일부 다른 열 이 포함되어 있습니다 . 그들은 모두 새롭게 업데이트되었습니다. RANGE_HI_KEY아래 표의 히스토그램에서 가장 높은 상한 열 값입니다.

+-------------------------------------------------------------------------+----------+--------------+--------------+---------------------+--------------+------------+----------+---------------------+----------------+
|                                  name                                   | stats_id | auto_created | user_created | Leading column Type | RANGE_HI_KEY | RANGE_ROWS | EQ_ROWS  | DISTINCT_RANGE_ROWS | AVG_RANGE_ROWS |
+-------------------------------------------------------------------------+----------+--------------+--------------+---------------------+--------------+------------+----------+---------------------+----------------+
| PK_Reports_Documents                                                    |        1 |            0 |            0 | Stationary          |        18722 | 0          | 2228,526 |                   0 | 1              |
| _dta_index_Reports_Documents_42_1629248859__K1_K63_K14_K13_K22_K23_72_6 |       62 |            0 |            0 | Stationary          |        18698 | 0          | 2228,526 |                   0 | 1              |
| _dta_stat_1629248859_1_1_59                                             |       76 |            0 |            1 | Stationary          |        18686 | 50,56393   | 1        |                   0 | 13397,04       |
| _dta_stat_1629248859_1_22_14_18_12_6                                    |       95 |            0 |            1 | Stationary          |        18698 | 0          | 2228,526 |                   0 | 1              |
| _dta_stat_1629248859_1_7_14_4_23_62                                     |       96 |            0 |            1 | Stationary          |        18698 | 56,63327   | 21641,5  |                   0 | 14526,44       |
+-------------------------------------------------------------------------+----------+--------------+--------------+---------------------+--------------+------------+----------+---------------------+----------------+

sp_updatestats 통계를 업데이트하기 위해 매일 밤 실행되도록 예약되어 있습니다.

답변:


10

이에 대한 간단한 해결책이 있습니다.

모든 _dta_...통계를 삭제하고 맹목적으로 DTA 권장 사항 적용을 중단하십시오.

추가 정보

특정 문제는 해당 열에 대한 여러 통계 세트가 있다는 것입니다. 추가 dta통계는 데이터를 샘플링하여 작성되었습니다 (인덱스와 연관되지 않은 통계의 기본 동작).

샘플링 된 통계의 경우와 마찬가지로 결과 히스토그램은 전체 데이터 범위를 다루지 않았습니다. 질문의 쿼리에서 히스토그램 외부에있는 값을 선택하여 1 행으로 추정되었습니다.

동일한 열에 대해 여러 통계 세트가 존재하는 경우 쿼리 최적화 프로그램의 정확한 동작은 완전히 문서화되어 있지 않습니다. 샘플링보다 '전체 스캔'통계를 선호하는 경향이 있지만, 최근 통계보다 더 최근에 업데이트 된 통계를 선호합니다.


이것은 실제로 작동합니다. 그러나 _dta_통계를 만들지 않았지만 DB를 처음 본 이후로 거기에있었습니다. 그래도 권장 사항을 사용하면 이러한 부작용이 발생할 수 있다는 것을 몰랐습니다.
user1151923
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.