Правильное значение коэффициента заполнения для кластерных индексов с суррогатными идентификационными ключами

У меня есть большая таблица, которая имеет кластерный индекс с идентификатором первичного ключа. Я выбираю правильное значение коэффициента заполнения для этой таблицы, чтобы минимизировать разбиение страницы. Мы поддерживаем индексы, используя скрипт, запускаемый ежедневно, который измеряет фрагментацию и предпринимает соответствующие действия. Таблица содержит столбцы переменной длины.

Моей первой мыслью было установить его равным 100 (поскольку записи должны быть записаны только в конец таблицы), но я предполагаю, что изменения в столбцах переменной длины также могут привести к расщеплению страницы, поэтому я сейчас поворачиваюсь к 90.

Любой совет приветствуется.

Это зависит

Это балансирование. Если ваша таблица интенсивно читается, с небольшим количеством обновлений или удалений, то по умолчанию (то есть 100) должно быть в порядке.

Если ваша таблица очень интенсивно пишет, с большим количеством обновлений, то значение ниже 80 может быть более подходящим.

Там нет волшебной формулы для этого материала. (AFAIK, если есть, пожалуйста, дайте мне знать). Лучше всего иметь тестовую среду, иметь некоторую рабочую нагрузку для тестирования. Внесите изменения и посмотрите, как ваша база данных работает с нагрузкой.

Ник в значительной степени прав.

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

(Несмотря на это, существует 5 типов разбиения страниц, которые может выполнять механизм хранения, но не все из них вызывают фрагментацию и перемещение данных - тот, который вы получаете при вставке монотонно увеличивающихся значений идентификаторов, является разделением в конце страницы. Но Я отвлекся...)

Я помог многим клиентам в этом, и я написал BOL вокруг всего этого - если вы хотите просто выбрать значение в качестве доли в земле, 70% увидели наибольший успех. Как говорит Ник, следите за настройками и настройкой.

Выбор коэффициента заполнения для любого индекса - это балансирование между активностью, которая увеличивает наполненность страницы до 100%, и как часто вы можете предпринять корректирующие действия для сброса коэффициента заполнения. Вам нужно подумать о том, сколько места изначально будет «потрачено впустую» на страницах, если вы установите коэффициент заполнения очень низким, например, 50%, но опять же я увидел, что это подходит в некоторых случаях.

Вы должны также рассмотреть, как будет использоваться индекс. Если это только для одноэлементных поисков, вам может понадобиться более низкий коэффициент заполнения и больше времени между перестроением / дефрагментацией, поскольку вы не собираетесь тратить слишком много операций ввода-вывода / памяти из-за наличия большого количества малонаселенного кластеризованного индекса в памяти. Для сканирования большого диапазона вам нужно, чтобы коэффициент заполнения был немного выше, чтобы повысить эффективность ввода-вывода и эффективность памяти.

Есть также вопрос OLTP против DW - обычно DW не меняется, поэтому индексы будут иметь 100% коэффициент заполнения. OLTP - сложная часть.

После того, как вы разобрались с кластеризованным индексом, помните, что некластеризованным тоже понадобится внимание, поскольку они, скорее всего, будут фрагментированы.

При сбросе коэффициента заполнения помните, что у вас есть выбор между восстановлением и дефрагментацией. DBCC INDEXDEFRAG / ALTER INDEX ... REORGANIZE в некоторых случаях может сбрасывать коэффициент заполнения для индексов, которые не сильно фрагментированы.

Надеюсь это поможет!

(Извините за «чрезмерный ответ» - одна из моих горячих кнопок, написав код :-)