Кластерный индекс для часто меняющейся ссылочной таблицы одного или нескольких внешних ключей

Question

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

Table 1 "Collection" collection_pk int (among other fields)
Table 2 "Item" item_pk int (among other fields)
Reference Table "Collection_Items" collection_pk int, item_pk int (combined primary key)

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

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

ЧАСТЬ ВОПРОСА: Поскольку таблица «Collection_Items» очень динамична, не будет ли значительный удар по производительности при постоянном преобразовании строк таблицы из-за кластеризованного индекса?

Если да, что я должен сделать, чтобы минимизировать это?

Answer 1

Предполагается, что вы удалили и повторно вставили набор строк для данного (составного) первичного ключа:

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

С точки зрения производительности, безусловно, кажется, что кластерный индекс - это путь ... хотя некоторые эксплуатационные соображения могут превзойти это. (Сколько удалений / вставок, частоты, таблицы, растущей в конце [значения идентичности?] Или в середине [вставка новых значений PK], общий размер, частота обновлений в сравнении с проблемами параллелизма / блокировки и т. Д. И т.

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

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

- Обновление на основе первого комментария ------------------

Мой первоначальный ответ был основан на следующих предположениях:

• Все строки, отбрасываемые в рамках данной транзакции (т. Е. Оператор INSERT или DELETE), относятся к одной коллекции. То есть N элементов будут добавлены / отброшены для одного набора.
• Единственный (и предпочтительно кластеризованный) индекс будет существовать для столбцов (Collection_pk, Item_pk), с Collection_pk в виде первого столбца.

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

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

Если существует индекс секунда (Item_pk, Collection_pk), который был бы необходим, если бы вам приходилось выполнять поиск по элементу, тогда он становится сложным. В этом случае:

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

Звучит так, как будто у вас нет и вам не нужен второй индекс, поэтому не беспокойтесь об этом.