Лучше использовать один сложный запрос или несколько более простых?

Question

Какой вариант лучше:

1. Написание очень сложного запроса с большим количеством объединений, или
2. Написание 2 запросов один за другим, применение полученного результирующего набора обработанного запроса к другому.

Answer 1

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

Если вы возражаете против объединения двух запросов, вы можете в конечном итоге отправить много повторяющихся данных междуСУБД и приложение.Если каждая из 10 000 строк в таблице T1 объединяется со средним числом 30 строк из таблицы T2 (таким образом, в общей сложности возвращается 300 000 строк), возможно, вы многократно отправляете много данных обратно клиенту.Если размер строки (соответствующей проекции) T1 относительно мал, а данные из T2 относительно велики, то это не имеет значения.Если данные из T1 велики, а данные из T2 малы, это может иметь значение;измерить, прежде чем принять решение.

Answer 2

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

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

Я привык выбирать требуемые первичные ключи из таблицы A, выбирать требуемые первичные ключи из таблицы B и т. Д. Присоединиться к ним и выбрать окончательный набор первичных ключей. Используйте выбранные первичные ключи, чтобы вернуться к таблицам и получить значения данных.

Как администратор БД, я теперь понимаю, что этот метод привел к меньшей очистке кеша данных и стал лучше играть с другими, использующими БД (как упомянул Амир Раминфар).

Однако это требует использования временных таблиц, которые не нравятся некоторым местам / администраторам баз данных (несправедливо на мой взгляд)

Answer 3

Предполагая, что «лучше» означает «быстрее», вы можете легко протестировать эти сценарии в тесте junit.Обратите внимание, что определяющим фактором, который вы не сможете получить из модульного теста, является задержка в сети.Если база данных находится рядом с вашей машиной, на которой вы запускаете модульное тестирование, вы можете не увидеть различий в производительности, связанных с сетью.Если ваши производственные серверы находятся в другом городе, стране или континенте из базы данных, сетевой трафик становится более узким местом.Вы не хотите переходить туда-сюда по проводам - ​​вам, скорее всего, захочется совершить одну поездку в оба конца и получить все сразу.

Опять же, все зависит:)

Answer 4

В крупных компаниях они предпочитают вариант 2, потому что вариант 1 будет загружать процессор базы данных. Это приводит к тому, что все другие соединения будут медленными, а все - узким местом. При этом все зависит от ваших данных и суммы, к которой вы присоединяетесь. Если вы присоединяетесь к 10000-1000, то вы получите 10000 x 1000 записей. (При условии внутреннего соединения)

Возможный дубликат MySQL JOIN Злоупотребление? Насколько плохо это может быть?

Answer 5

Многое зависит от фактического запроса и фактической базы данных, то есть SQL, Oracle mySQL.

Answer 6

Это может зависеть от многих вещей:,

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

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

Если вы используете MySQL (и, может быть, Oracle?), Вы можете использовать

EXPLAIN SELECT ..... 

и он даст вам много информации о том, как он выполнит запрос, и как вы можете его улучшить и т. Д.