У меня есть код, который использует долго SELECT
заявления, которые обычно LEFT JOIN
различные столы друг на друга, используя какой-то id
с или key
s, чтобы присоединиться к данным.
Результат этого SQL затем вводится в конструкцию класса PHP. Результат может содержать например
Код, который у меня есть, не очень хорошо структурирован, поэтому я думаю вместо одного длинного SQL
запрос, чтобы разделить его на несколько (т.е. в нашем случае 3) меньший простой SQL SELECT
s. Преимущества состоят в том, что код будет чище, проще для понимания и может быть лучше преобразован в более мелкие, более значимые классы и функции.
Но прежде чем приступить к демонтажу большого количества похожих SQL-операторов, я хотел проверить, имеет ли смысл с точки зрения производительности разбивать SQL-запрос. Потому что, в качестве альтернативы, я могу сохранить длинный SQL как есть и все еще иметь возможность реорганизовать мой код в более значимые классы и функции, но просто по-другому.
ВопросВ конце, учитывая, как PHP и MySql работают вместе, есть ли ощутимое преимущество в использовании более длинных SQL с несколькими объединениями по нескольким вызовам более коротких SQL (возможно, без каких-либо объединений)?
Как и в большинстве вещей MySQL, это зависит. Вам действительно нужно проверить, чтобы узнать.
На каждый запрос SQL, отправляемый в базу данных, накладные расходы (накладные расходы на синтаксический анализ, подготовку запроса, выполнение, подготовку результатов, ответ на выборки, очистку). И именно поэтому большое количество циклических обращений к базе данных с небольшими запросами (например, очень узкий цикл, получение одной строки на запрос) намного менее эффективно, чем один запрос, который возвращает все строки.
С другой стороны, вплоть до MySQL 5.6 единственным используемым методом соединения, который использовал оптимизатор, были вложенные циклы. Если нет подходящих индексов или вводящей в заблуждение статистики …
«Большой» запрос (то есть тот, который включает в себя десятки таблиц, миллионы и миллионы строк) может быть проблематичным с точки зрения производительности.
Но сервер базы данных обычно работает адекватно с обычными операциями соединения на разумных размерах и соответственно проиндексированных наборах. И операция соединения на сервере базы данных часто более эффективна, чем эквивалентная операция, выполняемая кодом, выполняющимся на сервере приложений.
Q: Есть ли ощутимая разница?
A: По идее может быть. (В теории нет разницы между теорией и практикой. На практике есть.)
Преимущество выполнения одного запроса по сравнению с тысячами запросов меньше затрат, и можно измерить разницу.
Недостатком одного запроса является то, что запрос может потребовать от MySQL выполнения такой большой работы, что производительность становится критической, и иногда мы можем добиться большей эффективности, разбивая запрос на управляемые фрагменты. Обычно мы не замечаем издержек при выполнении нескольких запросов … именно когда мы сталкиваемся с тысячами обходов базы данных, мы сталкиваемся с проблемами производительности и масштабируемости.
Чтобы действительно выяснить, поскольку вы уже думаете о разбиении запроса, продолжайте и разбивайте запрос на отдельные запросы, которые вы планируете выполнить, и тестируйте.
(Я сосредоточился на эффективности со стороны сервера баз данных, а не на производительности сервера приложений … Я также думал о том, чтобы сервер баз данных находился на одном хосте с сетевым соединением между приложением сервер и база данных … миллисекундные обходы сети начинают складываться, когда вы попадаете в десятки тысяч обходов.)
По моим оценкам
Длинный SQL выигрывает, скорее всего, из-за того, что PHP обрабатывает больше строк кода в целом, для моего конкретного случая.