Я пытаюсь понять, как работает выборка статистики, и ожидаемо ли приведенное ниже поведение при выборочных обновлениях статистики.
У нас есть большая таблица, разделенная по дате, с парой миллиардов строк. Дата раздела является предшествующей рабочей датой и, следовательно, является восходящим ключом. Мы только загружаем данные в эту таблицу за предыдущий день.
Загрузка данных происходит в одночасье, поэтому в пятницу, 8 апреля, мы загрузили данные за 7-е.
После каждого запуска мы обновляем статистику, хотя берут образец, а не FULLSCAN.
Возможно, я наивен, но я ожидал, что SQL Server определит самый высокий ключ и самый низкий ключ в диапазоне, чтобы обеспечить точную выборку диапазона. Согласно этой статье :
Для первого сегмента нижняя граница - это наименьшее значение столбца, по которому генерируется гистограмма.
Тем не менее, он не упоминает последний сегмент / наибольшее значение.
С обновленным статистическим обновлением утром 8-го числа выборка пропустила самое высокое значение в таблице (7-е).
Поскольку мы выполняем большое количество запросов к данным за предыдущий день, это привело к неточной оценке мощности и истечению времени ожидания ряда запросов.
Разве SQL Server не должен определять максимальное значение для этого ключа и использовать его как максимальное RANGE_HI_KEY? Или это только один из ограничений обновления без использования FULLSCAN?
Версия SQL Server 2012 SP2-CU7. В настоящее время мы не можем выполнить обновление из-за изменения в OPENQUERYповедении в пакете обновления 3, который округлял числа в запросе связанного сервера между SQL Server и Oracle.