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

Question

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

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

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

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

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

• Будет ли FK-index поглощать слишком много пространства \ времени, так как в таблице растет несколько миллионов записей?
• В таком случае стоит ли переходить на FK-индекс "каждый раз"?

• В каком случае я не применяю FK или Index это или не делаю ни одного из них (конечно, я могу обработать ЛОТ из приложения)

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

Спасибо.

Answer 1

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

Answer 2

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

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

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

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

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

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

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

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

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

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

Answer 3

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

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

Answer 4

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

• FK-index добавляет немного пространства / времени, но оно того стоит
• Да, стоит
• ФК поставляется с индексом
• FK хороши для соединений; другие поиски - это совсем другая история.

---

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

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

---

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