Цитата:
Сообщение от
Masel
[B]
По поводу расчета кардинальности На сколько я помню там было очень много странных планов, и пришлось много план гайдов сделать, чтобы снять "пожар" начальный. Больше всего такое удивляло. Есть запрос к таблице в 100 тысяч строк с единственным фильтром по полю из некластерного индекса. Тут даже без статистики понятно, что оптимизатор должен сделать index seek по этому полю и далее по результату lookup на кластерный. Но оптимизатор ищет по кластерному. Пересчитываешь статикику фулсканом, ставишь конкретные значения параметров, все равно кластерный индекс. Поведение такое, как будто там 10 строк. При переключении на старый алгоритм все эти странности пропадают.
Похоже там что-то со статистикой не так, а именно с гистограммами значений.
В моем случае в таблице 3 млн записей.
В индексированном поле по которому идет фильтрация всего 20 записей имеют непустое значение (и все разное)
Пробовал смотреть для индекса статистику командой
DBCC SHOW_STATISTICS
в разделе с гистограммами значений только одно значение после обычного обновления статистики командой UPDATE STATISTICS tablename (думает 7 секунд)
А если
UPDATE STATISTICS tablename WITH FULLSCAN (думает 3 минуты)
то в гистограмме видно все 20 значений и план запроса выправляется
аналогичный эффект имеет
UPDATE STATISTICS tablename WITH FULLSCAN, INDEX (думает 20 секунд)
только работает намного быстрее.
Жаль что в 2012-й отключили index hint
Он бы решил проблему.