Являются ли объединения на FK быстрее, чем объединения без FK? - PullRequest
Новая
       38

Являются ли объединения на FK быстрее, чем объединения без FK?

7 голосов
/ 27 июня 2011

Допустим, у меня есть две таблицы: a и b: 

a {
 pk as int
 fk as int
 ...
}

b {
 pk as int
 ...
}

Я хочу объединить a и b в запросе, например, так: 

FROM a
JOIN b on a.fk = b.pk

Какие изследующие сценарии будут быстрее?

  1. a.fk настроен как внешний ключ для b.pk - b.pk проиндексирован
  2. a.fk настроен набыть внешним ключом в b.pk - b.pk не индексируется
  3. нет связи между таблицами - b.pk индексируется
  4. нет связи между таблицами - b.pk не индексируется

Бонусный вопрос - насколько быстрее / медленнее будет каждый из этих сценариев?

Если бы вы могли подтвердить свой ответ ссылкой, это было бы здорово,Спасибо!

Ответы [ 3 ]

5 голосов
/ 27 июня 2011

Лучшая практика

  1. Иностранные ключи - это инструмент реляционной целостности , а не инструмент производительности. Вы должны всегда создавать индексы для столбцов FK, чтобы уменьшить количество просмотров. SQL Server не делает этого автоматически.
  2. Как указано здесь Внешние ключи повышают производительность

По логике, это дает следующий рейтинг эффективности

  1. a.fk настроен как внешний ключ для b.pk - b.pk проиндексирован
  2. нет связи между таблицами - b.pk проиндексирован
  3. a.fk настроен как внешний ключ на b.pk - b.pk не индексируется
  4. нет связи между таблицами - b.pk не индексируется
1 голос
/ 28 июня 2011

Я тоже отвечу Ливену.Просто чтобы ответить на ваш бонусный вопрос о том, какой прирост производительности вы получите от создания индекса, ответ будет «Это зависит».

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

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

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

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

1 голос
/ 28 июня 2011

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

...