Есть ли проблемы с производительностью, если SQL-запрос содержит много объединений?

Question

Есть ли проблемы с производительностью, если SQL-запрос содержит много объединений?

Answer 1

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

• Количество соединений
• Структура таблиц
• Размер базы данных
• Наличие if и тип данных индексов
• Типы данных объединяемых значений
• и т. Д.

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

Answer 2

Да.

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

select book.title, chapter.page_count
from chapter
join book on book.bookid=chapter.bookid
where chapter.subject='penguins'

Запрос, вероятно, будет сначала читать таблицу глав в поисках совпадений для «пингвинов», а затем присоединяться к «Книге». Если Bookid является первичным ключом книги или, по крайней мере, проиндексирован, это будет очень быстро. Но если нет, то мы должны были бы выполнить последовательное чтение Книги в полном файле. В зависимости от движка и других факторов, нам может потребоваться перечитать всю таблицу Book для каждой найденной записи главы . Это может занять много времени.

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

Соединения всегда стоят вам что-то . Но объединения, для которых требуется чтение всего файла, особенно многократное чтение, стоят дорого. Некоторые движки баз данных уменьшают эти затраты, распознавая, что это происходит, и могут загрузить таблицу в память и использовать ее повторно, обычно выполняя какой-то поиск по хешу. Это все еще дорого, но не так плохо.

Научитесь читать план объяснения. Они могут очень помочь в анализе ваших запросов, выяснить, где они плохие, и очистить их. Лично, если запрос явно не прост, например, «выбрать что-либо из таблицы, где primary_key = что угодно», я проверяю план объяснения просто для уверенности.

Answer 3

Один из лучших способов повысить JOIN производительность ограничивает количество строк нужно присоединиться.

Подробнее в этой статье

Настройка производительности соединений SQL Server

Answer 4

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

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

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

Но, как говорится, YMMV.

Answer 5

Да, если вы используете много объединений в SQL, это повлияет на вашу производительность.