четверг, 18 августа 2011 г. - www.msmirnov.ru

Как заставить работать filtered indexes в MS SQL Server 2008.

Недавно мы столкнулись со следующей проблемой – создали несколько filtered indexes, которые не хотели работать – оптимизатор не хотел их использовать, даже если условия запроса удовлетворяли условиям индекса.

В Books online проблема описана довольно скупо, но вот что удалось выяснить – для нормальной работы filtered indexes необходимо произвести те же настройки, которые нужны для indexed views или indexed computed columns, а именно (http://msdn.microsoft.com/en-us/library/ms175088.aspx):

ANSI_NULLS ON
ANSI_PADDING ON
ANSI_WARNINGS ON
ARITHABORT ON
CONCAT_NULL_YIELDS_NULL ON
NUMERIC_ROUNDABORT OFF
QUOTED_IDENTIFIER ON

После включения этих опций filtered indexes начинают работать как надо.
Мой сайт - www.msmirnov.ru

8 комментариев:

  1. расскажи подробнее, многое ли дает фильтеред индекс?
    Только то, что он меньше обычного, или за счет внутренней структуры данных в самом индексе есть выигрыш?

    Для каких данных вы его делали? Почему обычный не устроил?

    Раскрой попобробнее, plz, это мне интересно ... просто примеры, которые я видел - они какие-то синтетические, хотелось бы услышать реальную success story.

    ОтветитьУдалить
  2. Дело в том, что у нас есть довольно большие индексированные таблицы - сотни миллионов записей.
    Понятно, что вставка в такие таблицы занимает много времени. Большую часть этого времени занимает перестроение индексов.

    В наших условиях можно было создать несколько фильтрованных индексов, покрывающих разные части таблицы вместо одного обычного индекса.

    Это дало прирост производительности при вставке в таблицы.

    ОтветитьУдалить
  3. т.е. вы взяли обычный индекс и разбили его поменьше, чтоб быстрее перестраивался? А fillfactor не помогал?

    ОтветитьУдалить
  4. Filtered Index - это не "индекс разбили поменьше", это значит, что записи, не удовлетворяющие критерию, вообще не попадают в индекс.
    Это значит, что вставка таких записей в таблицу не будет приводить к вставке/перестроению индекса (что повышает скорость записи) и что сам индекс будет меньше, и глубина его будет меньше (потенциально), и содержать он будет только то, что необходимо (считай это дополнительным пред-просчитанным критерием, чтоли), что, в идеале, приведёт к повышению скорости выборки.

    А вот про хинты из статьи я не знал... Как-то у нас они срабатывают, может DBAшники эти хинты уже применяли...

    ОтветитьУдалить
  5. что записи, не удовлетворяющие критерию, вообще не попадают в индекс
    это все ясно. Вопрос был - не помог ли в задаче - вставлять быстрее - простой филфактор?

    ОтветитьУдалить
  6. Привёл бы в конечном итоге к бОльшей фрагментации индекса, большей глубине оного, большему объёму и к вопросу "зачем хранить там то, что всё равно не нужно?" :)

    ОтветитьУдалить
  7. Филфактор, Саш, логические размеры индекса никак не сокращает. Он только однократно изменяет место на диске, занимаемое индексом (грубо говоря).
    К тому же, филфактор не поддерживается в заданном значении по мере работы с индексом - он устанавливается однакратно при перестроении индекса.

    ОтветитьУдалить