Дня доброго.
Никогда такого не было и вот опять...

Есть план запроса, который не попадает в статистику:
http://prntscr.com/plsvvx

Ну понятно, SQL ждал 3700 строк, выделил под них память, пришло 20000 строк, памяти не хватило, стал писать в tempdb

Сделал updatestatistics по этой таблице, DBCC FREEPROCCACHE

Повторный запрос выдал тот же план выполнения.

Что я забыл?

Неудачное значение для статистики

Не в тот столбец гистограмммы вошло

В статистике - пусто
http://prntscr.com/plt4xx

Грешу на 183 млн. строк, судя по манам,
http://sql-ex.ru/blogs/optimization/statistics-in-sql-server.html
для от ста млн. строк для сбора статистики на больших таблицах нужны какие-то заморочки.

Ну и данные надо проверять, судя по всему в таблицу струячатся дубли.

Ну и собственно, если разбить 183 млн на 200 частей - это не сильно поможет.
Не знал, что гистограмма ограничена 200 строками, че так мало?

Партиционируй

(0)
попробуйте трюк с фильтруемыми индексами.

интересная тема... сделаю закладочку.

отфильтрованная статистика (Create Statistic с предикатом Where) не подходит для вашего случая?

(3) Скажи спасибо 1с-овцам которые пихают splitter первым полем во все таблицы. Значения гистограммы хранятся для 1-го поля, а оно у тебя, как и у большинства, состоит из 1 значения. Статистике превед.

+(9) статистика считается на основании гистограммы первого поля и данных о плотности по комбинации с другими полями. Соответственно норм люди первым полем делают высокоселективные данные, а не поле из значения разделителя, ЛОЛ.

После темы с индексами на партнерке понятно что для них производительность на десятом месте и относится к базе как к помойке это норма.

(3) ради эксперимента попробуй выключить разделение в базе на копии, как это отразится на статистике?

(11) В 9.* они на NoSQL перейдут - вот тогда точно помойка будет ))