Статистика є актуальною, але оцінка неправильна

Щойно я dbcc show_statistics ('Reports_Documents', PK_Reports_Documents)отримую такий результат для ідентифікатора звіту 18698:

Для цього запиту:

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

Я отримую план запитів, який робить кластерний пошук шукати, PK_Reports_Documentsяк очікувалося.

Але що мене бентежить - це неправильне значення для оціночної кількості рядків:

Відповідно до цього :

Коли зразок запиту WHERE значення пункту дорівнює значенню RANGE_HI_KEY гістограми, SQL Server використовує стовпець EQ_ROWS у гістограмі для визначення кількості рядків, рівних

Це також я би очікував, що це буде, однак, як здається, це не так у реальному житті. Я також спробував деякі інші RANGE_HI_KEYзначення, які були присутні у гістограмі, наданій show_statisticsта пережиті тим же. Здається, ця проблема в моєму випадку викликає деякі запити щодо використання дуже неоптимальних планів виконання, що призводить до часу виконання декількох хвилин, тоді як я можу змусити його запуститись за 1 сек із підказкою.

Загалом: Чи може хтось пояснити мені, чому EQ_ROWSз гістограми не використовується для розрахункової кількості рядків і звідки береться неправильна оцінка?

Трохи більше (можливо корисна) інформація:

• Автоматичне створення статистики увімкнено, і вся статистика є актуальною.
• Запитувана таблиця містить близько 80 мільйонів рядків.
• PK_Reports_Documentsявляє собою комбінацію ПК, що складається з ReportID INTіDocumentID 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 планується проводити щовечора, щоб оновити статистику.

Для цього є просте рішення:

Відкиньте всю _dta_...статистику та припиніть сліпо застосовувати рекомендації DTA.

Більше інформації

Особлива проблема полягала в тому, що для відповідної колонки було кілька наборів статистичних даних. Додаткова dtaстатистика створювалася шляхом вибірки даних (поведінка за замовчуванням для статистики, не пов'язаної з індексом).

Як це часто трапляється з вибірковою статистикою, отримані гістограми не охоплювали повного діапазону даних, що мають відношення. У запиті вибиралося значення, яке знаходилось поза гістограмою, в результаті чого оцінювались 1 рядок.

Точна поведінка оптимізатора запитів, коли існує кілька наборів статистики для одного стовпця, не повністю задокументоване. Він, як правило, надає перевагу статистиці "повного сканування" перед вибіркою, але також надає перевагу більш нещодавно оновленій статистиці старішим.