производительность - выбор одного соединения против нескольких простых выборов

Question

Что лучше с точки зрения производительности?

Answer 1

Есть только один способ узнать это: Time it.

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

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

Answer 5

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

У меня был медленный и сложный запрос с множеством объединений. Затем я разделил его на 2 или 3 менее сложных запроса. Прирост производительности был поразительным.

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

Answer 6

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

Ответ на этот вопрос зависит от (от макушки):

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

Answer 7

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

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

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

Answer 8

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

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