LEFT JOIN против нескольких операторов SELECT

Question

Я работаю над чужим PHP-кодом и вижу этот шаблон снова и снова:

(псевдокод)

result = SELECT blah1, blah2, foreign_key FROM foo WHERE key=bar

if foreign_key > 0  
  other_result = SELECT something FROM foo2 WHERE key=foreign_key  
end

Код должен быть разветвлен, если в другой таблице нет связанной строки, но разве это нельзя сделать лучше, выполнив LEFT JOIN в одном операторе SELECT? Я упускаю какой-то выигрыш в производительности? Проблема переносимости? Или я просто придираюсь?

Answer 1

Один SQL-запрос приведет к большей производительности, так как SQL-серверу (который иногда не использует одно и то же местоположение) просто нужно обработать один запрос, если вы будете использовать несколько SQL-запросов, вы добавите много дополнительной информации: 1001 *

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

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

Answer 2

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

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

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

Это обновление существенно исправило время отклика, вплоть до нескольких секунд, потому что было проще сделать много простых «однократных снимков» для получения необходимых данных.

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

Answer 3

Учитывая, что в одном обращении к базе данных у вас есть все данные, которые вам нужны, один оператор SQL будет лучше работать в 99% случаев. Не уверен, что в этом случае соединения создаются динамически или нет, но если это так, это дорого. Даже если процесс при повторном использовании существующих соединений СУБД не получает оптимизацию запросов, это лучший способ и не использует отношения.

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