Отношения SQL и индексы

Question

У меня есть приложение на сервере MS SQL, где я определил свои отношения и первичные ключи.

Однако нужно ли дополнительно определять индексы для полей отношений, которые иногда не используются в соединениях и просто как часть предложения where?

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

Answer 1

На эту тему написано несколько очень толстых книг!

Вот несколько практических примеров: -

Не надо индексировать (кроме PK) любую таблицу с <1000 строками. </p>

В противном случае индексируйте все свои ФК.

Изучите свой SQL и найдите предложения where, которые больше всего уменьшат ваши результирующие наборы и проиндексируют этот столбец.

например. Дано:

    SELECT OWNER FROM CARS WHERE COLOUR = 'RED' AND MANUFACTURER = "BMW" AND ECAP = "2.0";

У вас может быть 5000 красных машин из 20 000, так что индексация не сильно поможет. Однако у вас может быть только 100 BMW, поэтому индексирование MANUFACURER немедленно сократит ваш набор результатов до 100, и вы можете устранить синие и белые автомобили, просто просматривая сто строк.

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

Answer 2

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

Создание индексов для запросов, которые вы используете, будь то соединения или предложение WHERE - это путь.

Answer 3

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

Итак, что я делаю, это помещаю в очевидные индексы и взаимосвязи, а затем оптимизирую после того, как приложение строится на возможных медленных запросах.

Answer 4

Определение отношения не создает индекс.

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

Answer 5

Соображения базы данных

При разработке индекса учитывайте следующие рекомендации базы данных: Большое количество индексов в таблице влияет на производительность операторов INSERT, UPDATE, DELETE и MERGE, поскольку все индексы должны быть соответствующим образом скорректированы при изменении данных в таблице.

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

2. Использование множества индексов для повышения производительности запросов в таблицах с низким обновить требования, но большие объемы данных. Большое количество индексы могут помочь производительности запросов, которые не изменяют данные, такие как операторы SELECT, потому что оптимизатор запросов имеет больше индексы на выбор, чтобы определить самый быстрый метод доступа.

3. Индексирование небольших таблиц может быть неоптимальным, поскольку оно может занять Оптимизатор запросов дольше обрабатывает индекс для поиска данных, чем выполнить простое сканирование таблицы. Поэтому индексы на маленьких столах может никогда не использоваться, но все равно должен храниться в виде данных в таблица изменений.

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

- Stay_Safe -

Answer 6

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

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

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

Answer 7

Я бы начал с того, чтобы убедиться, что у каждого ПК и ФК есть индекс.

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