Стоит ли назначать индекс FK?

Question

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

Ну, я знал, что поддерживать индексы PK автоматически и поэтому помогает ускорить доступ к данным. Теперь из этого обсуждения я получаю, что если я использую JOINs в своих SQL-Queries, тогда я использую FK и индексирую его, чтобы сделать операции JOIN эффективными.

Например, у меня есть таблица OrgMaster (содержит все записи Org), то у меня есть BookingMaster таблица (содержит все записи заказа). Теперь OrgMaster.Id ссылается на «BookingMaster.OrgId». Итак, у меня есть FK для отношений OrgId-to-Id, и я shud 'index' его для лучшей производительности любой операции JOIN между обеими этими таблицами. Я правильно понял?

Все вышеперечисленное - за счет дополнительных накладных расходов пространства и времени (при вставке записи в таблицу с помощью FK).

Я прошу вас предоставить мне список пунктов, которые будут рассматриваться, как:

• ли FK-индекс собирается съесть слишком много пространства \ времени, как таблица растет несколько миллионов записей?
• В этом случае стоит ли искать «FK-index» каждый раз?

• В каком случае изгоняются я НЕ применять FK или индекс его или делать ни один из него (конечно, я могу справиться с ЛО из приложения)

• Любые другие сложно SpeedUp РЕГИСТРИРУЙТЕСЬ или другие такие трудоемкие поиски ?

спасибо.

Answer 1

Ваши вопросы:
ли FK-индекс собирается съесть слишком много места/времени в таблице растет несколько миллионов записей?

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

В этом случае, стоит ли каждый раз использовать FK-индекс?

Обычно да, но это действительно случайная ситуация. Считайте, что нужно учитывать, а не простой индекс FK - это индексы, которые включают дополнительные столбцы и могут использоваться как для поиска, так и для покрытия [частей] списка выбора. Опять же, принятие решения по такой альтернативе (или дополнительным индексам) является случайным, извините ;-) ...

В каком случае я НЕ должен применять FK или индексировать его или ничего не делать (конечно, я может обрабатывать LOT из приложения)

Конечно, все такие случаи исключают те, в которых важно, чтобы ссылочная целостность была встроена непосредственно в dbms (такую ​​целостность можно альтернативно управлять на уровне приложения/процессов которые вставляют и удаляют строки в базе данных)

• случаи, когда большая часть [времени или ресурса] критические запросы подразумевают использование других фильтров в таблице и, таким образом, SQL может затем разрешить JOIN, проверяя значения в таблице per-se (или в индексе покрытия, в частности, тот, где FK не является первым указанным столбцом) для [small] подмножество возможных результатов, полученных этими другими фильтрами.
• случаи, когда таблица таблицы относительно небольшая (таблицы поиска и т. Д.), Так как SQL часто определяет стратегию сканирования для них, а также по мере их кэширования). Но тогда, они маленькие, и, как правило, относительно статична, поэтому стоимость дополнительных индексов не будет проблемой ...
• может быть несколько больше случаев ...

Любое другое сложно ускорить JOIN или другие такие трудоемкие поиски?

Когда дело доходит до перемещения данных вокруг, например, когда добавляется значительное количество данных и т. Д. Часто стоит отказаться от индексов (или некоторых из них), сделать CUD (INSERT/UPDATE/DELETE), а затем повторно создайте индексы. Конечно, это не всегда возможно, если база данных одновременно просматривается во время обновлений и т. Д.

Также следите за FILL_FACTOR, связанный с индексами, как разумный выбор для них держать указательный fragmentatation до минимума (за счет потребления, по сравнению с немного больше пространства), по крайней мере между ППРОМ индексов

Answer 2

Я не эксперт, но я могу дать некоторые общие мнения о списке вопросов:

• FK-индекс добавляет немного пространства/времени, но он по-прежнему стоит
• да , стоит
• FK имеет индекс
• FK подходит для присоединения; другие поиски - совершенно другая история.

---

Для большинства поисков, она стоит не оптимизируя авансом, но ждать, пока наблюдая проблемы с производительностью, то:

1. меры точно
2. внести изменения
3. меру снова , сравните
4. если не набирает или не стоит проблемы, отмените изменения

---

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

Answer 3

Если вы хотите использовать ограничения ссылочной целостности, вы должны использовать внешние ключи.

Answer 4

Если вы нормализовали свои данные, вы должны использовать ограничения внешнего ключа; это единственный практический способ гарантировать, что ваши данные не являются недействительными.

Следует ли создавать индекс для этого внешнего ключа несколько сложнее. Создание индексов для внешних ключей не является автоматическим во всех РСУБД. Как и любой другой индекс, он торгует пространство и время вставки для более быстрого чтения (может быть особенно заметно, поскольку операции JOIN, как правило, относятся к более медленным операциям в вашей БД). Вам также необходимо рассмотреть вопрос о том, будет ли столбец FK охватываться другим индексом и, возможно, ему не понадобится его собственный индекс.