У меня есть большая таблица с кластеризованным индексом с первичным ключом идентификации. Я выбираю правильное значение коэффициента заполнения для этой таблицы, чтобы минимизировать разбиение страниц. Мы поддерживаем индексы с помощью сценария, запускаемого ежедневно, который измеряет фрагментацию и предпринимает соответствующие действия. Таблица содержит столбцы переменной длины.
Моя первая мысль заключалась в том, чтобы установить его на 100 (поскольку записи должны быть записаны только в этот конец таблицы), но я предполагаю, что изменения в столбцах переменной длины также могут вызвать разделение страниц, поэтому теперь я склоняюсь к 90.
Любые советы приветствуются.
Ник в значительной степени прав.
Если вы выполняете обновления, которые увеличивают размер записи на упакованных страницах, это приведет к разделению страниц, но кроме этого, с первичным ключом идентификации ничто не приведет к разделению страниц в кластеризованном индексе.
(Хотя это и сказано, есть 5 типов разделения страниц, которые может выполнять Storage Engine, и не все из них вызывают фрагментацию и перемещение данных - тот, который вы получаете при вставке монатонно возрастающих значений идентификаторов, является разделением в конце страницы. Но Я отвлекся...)
Я помог многим клиентам с этим и написал BOL вокруг всего этого - если вы хотите просто выбрать ценность как основную ставку, 70% добились наибольшего успеха. Как говорит Ник, отслеживайте и настраивайте при необходимости.
Выбор коэффициента заполнения для любого индекса - это баланс между тем, сколько действий происходит, доводя заполненность страницы до 100%, и как часто вы можете предпринимать корректирующие действия для сброса коэффициента заполнения. Вам нужно подумать о том, сколько места будет изначально «потрачено впустую» на страницах, если вы установите очень низкий коэффициент заполнения, например 50%, но опять же, я видел, что это уместно в некоторых случаях.
Вы также должны подумать о том, как будет использоваться индекс. Если это только для одноэлементного поиска, вам может сойти с рук более низкий коэффициент заполнения и больше времени между перестройкой / дефрагментацией, поскольку вы не собираетесь тратить слишком много операций ввода-вывода / памяти из-за наличия большого количества редко заполненного кластерного индекса в памяти. Для сканирования большого диапазона вам нужно немного увеличить коэффициент заполнения, чтобы увеличить эффективность ввода-вывода и памяти.
Также есть вопрос о OLTP и DW - обычно DW не меняется, поэтому индексы будут иметь 100% коэффициент заполнения. OLTP - сложная часть.
После того как вы отсортировали кластерный индекс, помните, что некластеризованные индексы тоже потребуют внимания, поскольку они, скорее всего, будут фрагментированы.
При сбросе коэффициента заполнения помните, что у вас есть выбор между восстановлением и дефрагментацией. DBCC INDEXDEFRAG / ALTER INDEX ... REORGANIZE в некоторых случаях может сбросить коэффициент заполнения для индексов, которые не сильно фрагментированы.
Надеюсь это поможет!
(Извините за "лишний ответ" - одна из моих горячих кнопок, написав код :-)
Это зависит
Это балансирующий акт. Если ваша таблица интенсивно читается, с небольшим количеством обновлений или удалений, тогда значение по умолчанию (100) должно быть в порядке.
Если ваша таблица очень интенсивна для записи и имеет много обновлений, то значение ниже 80 может быть более подходящим.
Для этого нет волшебной формулы. (AFAIK, если есть, дайте мне знать) Лучше всего иметь тестовую среду, иметь некоторую рабочую нагрузку для тестирования. Внесите изменения и посмотрите, как ваша база данных справится с рабочей нагрузкой.