Производительность - выбор одного соединения по сравнению с несколькими простыми выборами

Ответ 1

Существует только один способ узнать: время.

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

Недавно у меня было около 100 select-statements, которые я изменил в JOIN в моем коде. С несколькими индексами я смог перейти от 1 минуты до 0,6 секунды.

Ответ 2

Одно соединение обычно превосходит несколько отдельных выборок. Тем не менее, существует слишком много разных случаев, которые соответствуют вашему вопросу. Неразумно объединять их вместе одним простым правилом.

Что еще более важно, для следующего программиста, как правило, проще понять и пересмотреть следующий процесс, если вы и следующий программист "говорите на одном языке" при использовании SQL. Я говорю о языке наборов кортежей.

И не менее важно то, что физическому дизайну базы данных и дизайну запросов нужно сначала сосредоточиться на вопросах, которые приведут к десятикратному улучшению скорости, а не к 10% -ной скорости. Если вы делаете тысячи простых выборок по сравнению с одним соединением, вы можете получить десять за одно преимущество. Если вы выполняете три или четыре простых выбора, вы не увидите большого улучшения в том или ином виде.

Ответ 3

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

Алгоритм соединения с сервером базы данных - обычно - лучше, чем все, что вы могли бы придумать. Они знают больше о физическом вводе-выводе, кешировании и что-нет.

Это позволяет сосредоточиться на проблемной области.

Ответ 4

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

Ответ 5

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

У меня был медленный и сложный запрос с большим количеством подключений. Затем я разделил его на 2 или 3 менее сложных запроса. Увеличение производительности было удивительным.

Но в конце концов, "это зависит", вы должны знать, где узкое место.

Ответ 6

Как уже было сказано, нет правильного ответа без контекста.

Ответ на это зависит от (сверху):

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

Ответ 7

Если вы используете SQL Server (я не уверен, что это доступно для других РСУБД), я бы предложил вам связать план выполнения с результатами запроса. Это даст вам возможность точно определить, как выполняются ваши запросы (запросы) и что вызывает любые узкие места.

Пока вы не знаете, что делает SQL Server, я бы не стал подозревать, какой запрос лучше.

Ответ 8

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

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

Все зависит от размера вашего db, вашего запроса, индексов (включая и первичные и внешние ключи)... Невозможно прийти к выводу с да/нет по вашему вопросу.