Какой план запроса лучше?

Question

[Андрей Овсянкин]

Есть запрос, выбирающий примерно 100к строк.
У него был вот такой план выполнения
habrastorage.org/files/ac3/889/550/ac38895507ef4d0...
В нем видно 2 table scan, это условие вида:
LEFT JOIN table ON table.somefield = @param
Я добавил индекс по этому полю somefield, и план стал таким:
habrastorage.org/files/0a1/2be/863/0a12be86308c45d...
Время выполнения толком не изменилось. Можно ли сказать, какой из этих планов заведомо хуже?

Comments

[asd24]

После добавления нужного индекса, у вас должен был появиться в плане компонент Index Seek вместо Table Scan - этого не произошло..
Возможно, неверный индекс составили

[Андрей Овсянкин]

Поле с добавленным индексом имеет плохую селективность. Примерно 5-6 различных значений и каждое значение входит в выборку примерно с одинаковой вероятностью. Итого получается, что индекс выберет 5-6 наборов одинаковой длины по этому полю. Т.е. особой выгоды от этого индекса не будет, вот, скорее всего поэтому и Table Scan. Полагаю, что убрать скан по такому полю не получится.

[Anton Belichkov]

100к строк прям действительно так уж сильно необходимо?

Answer 1

[Anton Belichkov]

Без знания деталей сложно сказать, тем не менее... Нет, мне ни один из них не нравится!
Попробуйте жесткими хинтами отключить мозги серверу. Бывает option (loop join, force order) помогает лучше, чем создание индексов. Ну и в join-е пнуть table with(index(TMPIND_0)) или как его там.

Answer 2

[Fadmin]

Вы бы хоть запрос показали, а лучше с данными.
table scan и hash match говорят о том можно еще что то сделать,
вопрос в том надо ли?
Сильно медленно работает?
Индекс кластерный? Покрывающий ваш join?

Comments

[Андрей Овсянкин]

Пример привести слишком геморно будет. Работает не сильно медленно. Про покрытие join уточню, сейчас не в курсе.

Answer 3

[Eduard]

используйте set statistics io, time on для понимания что реально тормозит