Какие-то особые соображения при добавлении большого количества отсутствующих индексов внешнего ключа в существующую базу данных? - PullRequest
1 голос
/ 07 декабря 2011

Я работаю в системе, подкрепленной довольно большой базой данных SQL Server 2008, около 250 таблиц.После некоторой оптимизации производительности я обнаружил, что во многих таблицах отсутствовали индексы для внешних ключей.После более подробного изучения всех таблиц я определил около 150 внешних ключей с потенциально отсутствующими индексами.

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

Но так как я даже не близко к эксперту поОптимизация базы данных, я подумал, что перед тем, как начать добавлять все эти индексы, я бы запустил контрольный вопрос:

Вопрос:
Есть ли какие-то особые соображения, которые следует учитывать при добавлении такихбольшое количество индексов для существующей базы данных?

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

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

Ответы [ 2 ]

3 голосов
/ 07 декабря 2011

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

Просто убедитесь, что вы тестируете с реалистичными объемами данных и рабочими нагрузками.

3 голосов
/ 07 декабря 2011

Не думаю, что есть что-то особенное, кроме очевидных моментов, которые следует учитывать:

  • Требуется больше дискового пространства для индексов
  • Влияние на производительность, но это то, что должнобыть измеренным, а не угаданным (даже база данных, которая интенсивно вставляет / обновляет, обычно имеет больше операций чтения, чем записи; механизм должен найти строку, прежде чем ее можно будет обновить)
  • Расширение процесса генерации и управления DDL, чтобы обеспечитьчто теперь все индексы FK по умолчанию сценариев

Если ограничения уже существуют и отсутствуют только индексы, вам не нужно беспокоиться о самой большой потенциальной проблеме, которая является недействительными даннымичто нужно пересмотреть и исправить.Но из вашего вопроса я понимаю, что сами ФК уже есть.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...