Является ли более эффективным сделать один SQL SELECT с объединениями по сравнению с несколькими меньшими SQL?

У меня есть код, который использует долго SELECT заявления, которые обычно LEFT JOIN различные столы друг на друга, используя какой-то idс или keys, чтобы присоединиться к данным.

Результат этого SQL затем вводится в конструкцию класса PHP. Результат может содержать например

  • кривые коэффициенты
  • параметры продукта
  • данные испытаний

Код, который у меня есть, не очень хорошо структурирован, поэтому я думаю вместо одного длинного SQL запрос, чтобы разделить его на несколько (т.е. в нашем случае 3) меньший простой SQL SELECTs. Преимущества состоят в том, что код будет чище, проще для понимания и может быть лучше преобразован в более мелкие, более значимые классы и функции.

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

ВопросВ конце, учитывая, как PHP и MySql работают вместе, есть ли ощутимое преимущество в использовании более длинных SQL с несколькими объединениями по нескольким вызовам более коротких SQL (возможно, без каких-либо объединений)?

0

Решение

Как и в большинстве вещей MySQL, это зависит. Вам действительно нужно проверить, чтобы узнать.

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

С другой стороны, вплоть до MySQL 5.6 единственным используемым методом соединения, который использовал оптимизатор, были вложенные циклы. Если нет подходящих индексов или вводящей в заблуждение статистики …

«Большой» запрос (то есть тот, который включает в себя десятки таблиц, миллионы и миллионы строк) может быть проблематичным с точки зрения производительности.

Но сервер базы данных обычно работает адекватно с обычными операциями соединения на разумных размерах и соответственно проиндексированных наборах. И операция соединения на сервере базы данных часто более эффективна, чем эквивалентная операция, выполняемая кодом, выполняющимся на сервере приложений.

Q: Есть ли ощутимая разница?

A: По идее может быть. (В теории нет разницы между теорией и практикой. На практике есть.)

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

Недостатком одного запроса является то, что запрос может потребовать от MySQL выполнения такой большой работы, что производительность становится критической, и иногда мы можем добиться большей эффективности, разбивая запрос на управляемые фрагменты. Обычно мы не замечаем издержек при выполнении нескольких запросов … именно когда мы сталкиваемся с тысячами обходов базы данных, мы сталкиваемся с проблемами производительности и масштабируемости.

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

(Я сосредоточился на эффективности со стороны сервера баз данных, а не на производительности сервера приложений … Я также думал о том, чтобы сервер баз данных находился на одном хосте с сетевым соединением между приложением сервер и база данных … миллисекундные обходы сети начинают складываться, когда вы попадаете в десятки тысяч обходов.)

1

Другие решения

По моим оценкам

  • 10 000-кратное выполнение длинного оператора SQL занимает 1,5 секунды
  • 10 000-кратное выполнение эквивалентных более коротких операторов SQL занимает 2,43 секунды

Длинный SQL выигрывает, скорее всего, из-за того, что PHP обрабатывает больше строк кода в целом, для моего конкретного случая.

0

По вопросам рекламы [email protected]