Возможно, внешние ключи повреждают выполнение запросов

Question

Как я понял из this post, есть несколько сценариев, в которых внешние ключи могут улучшить производительность запросов.

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

---

1) Термин запрос представляется вводящим в заблуждение. Меня интересуют все виды штрафов за производительность.

2) Есть ли у кого-нибудь цифры реального мира об отрицательном воздействии на инструкции INSERT, DELETE или UPDATE (я знаю, что это зависит от конкретной системы, но тем не менее любые оценки реального мира будут оценены)?

Answer 1

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

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

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

Answer 2

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

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

Answer 3

Если внешние ключи оказали какое-либо воздействие таким образом, это было бы НА ВСТАВКАХ. База данных выполняет референтную проверку внешних ключей, когда записи создаются/изменяются, а не SELECT.

Answer 4

Я считаю, что отмеченное сообщение указало, что повышение индекса на FK-полях повышает производительность, а не только улучшение отношения FK. Существование FK в таблице не должно влиять на запрос SELECT, если только не выполняются операции JOIN, и в этом случае отношение FK и индекс FK к полям FK улучшат производительность.

Answer 5

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

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

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

Answer 6

Для INSERT/UPDATE/DELETE короткий ответ: «Да». База данных должна будет проверить целостность ссылочной целостности и разрешить создание/модификацию. Или в случае DELETE может быть какое-то каскадирование.

Для SELECT, это на самом деле совсем наоборот. У внешних ключей есть секретное преимущество, показывающее вам, где именно вы, скорее всего, выполняете сложные JOIN и имеете очень часто используемые поля. Это упрощает работу по индексированию, и вы можете в значительной степени гарантировать, что все ваши поля FK должны быть проиндексированы. Это значительно облегчает работу SELECTs .

Answer 7

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

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

Answer 8

Теоретически, да: для записи данных необходимо проверить ограничения.

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

• плохого дизайн схемы (отсутствующие индексы, плохо кластерный выбор индекса)
• раздора (блокирующая), опять-таки из-за плохой дизайн схемы (сканирование таблицы гарантии конфликтов блокировков)
• плохой дизайн запрос

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

My 2c: Никогда не Ограничения прав жертвы для некоторых неуловимых целей производительности. В очень редком случае, когда ограничения действительно являются проблемой, есть измерения, чтобы показать, что это так, и, как говорится: если вы должны спросить, сколько это стоит, вы не можете этого себе позволить. Если вы должны спросить, могут ли проблемы быть проблемой, вы не можете их удалить (не должно быть никакого преступления).

Answer 9

Если вы применяете ссылочную целостность, INSERT и UPDATE, которые влияют на поле FK, будут медленнее. Однако об этом обычно не о чем беспокоиться, тем более, что многие БД 80% читают/20% пишут. Это также цена, которую стоит заплатить.

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

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

Answer 10

Проверка внешнего ключа занимает больше времени, чем думает большинство людей. Текущий тест с Oracle 11g и таблицей с двумя внешними ключами показал, что время для вставки около 800 000 строк заняло 60 секунд с включенными внешними ключами, но только 20 секунд без внешних ключей. (Конечно, колонки с иностранными ключами были проиндексированы)

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

Answer 11

Внешние ключи замедляют вставки и изменения, поскольку каждая ссылка внешнего ключа должна быть проверена. Внешние ключи могут либо не влиять на выбор, либо ускорить его, в зависимости от того, использует ли СУБД индексацию внешнего ключа.

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

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

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