Вопрос: Существует ли разница между этими двумя запросами с точки зрения внутреннего выполнения?

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

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

Да, я в курсе, что sql - это декларативный язык.
И я понимаю, что where a = 1 && b = 1 и where b = 1 && a = 1 - это одно и то же.

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

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



Я прекрасно понимаю, что все эти три запроса дают один и тот же результат и мне было забавно получить советы "упростить" запрос.))))

miksoftА Вы планы этих запросов смотрели? Они разные/одинаковые?

Все три плана очень сильно отличаются.
Планы для вложенных запросов двухстрочные primary + derived
План для запроса без вложения однострочный simple.

MasterZivТы всё время пишешь && , в то время как нужно писать AND .

А собственно what's the problem?
У нас в продакшене весь мускульный код с ампрессандами...

MasterZivНа все такие вопросы тебе могут ответить два источника данных:
напечатанный план запроса



Я всегда думал, что план запроса используется лишь для проверки подцепились индексы или нет.
Мне почему-то всегда казалось, что внутри мускула все равно будет какая-то другая магия, нежели в explain.

MasterZivНа все такие вопросы тебе могут ответить два источника данных:
исходный код MySQL



На это, если честно, яиц не хватает. :-))))
Не осилю я такое...
Такие занятия - это для совсем головастиков, а я к таким не отношусь...
Всякие итмошники таких как мы называют быдлокодеры))))
И не без оснований, кстати)))
Но мы не обижаемся...
Я отлично понимаю что такое супер-пупер программист и более чем понимаю, что таким как я до них как до парижа раком...)))
а те, кто считает себя супер-пупер, то как правило 15 минут общения с ними бывает достаточно чтобы понять, что они просто ни разу в жизни не видели живого супер-пупера, вот и строят из себя звезду россии...
а все реальные супер-пуперы они не высовываются и особо на свет не лезут...)))

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

MasterZivЕсли ты хочешь выработать для себя правила, как лучше писать запросы, то вот они (в первом приближении):


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

MasterZiv-- не делай лишних подзапросов, если без этого никак. В том числе, не делай подзапросы во фразе FROM, если это не необходимо.


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

MasterZiv-- формулируй запрос в каноническом виде SELECT ... FROM t1 JOIN t2 ... LEFT JOIN t3 ... where ... [group by ... [having ]]

вообще непонятное правило...
я например, не знаю что такое неканонический вид...
я не понимаю это правило, потому что не знаю других форм селектов...
я реально не знаю как ещё можно это написать)))
ну не стану же я делать запрос from t selec * where join order group )))
оно просто выполняться не будет...)))

MasterZiv-- условия выборки пиши в WHERE
-- условия JOIN-ов -- в JOIN-ах во фразе ON.

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

MasterZiv-- используй параметры запросов.

Не понял этот пункт вообще...

miksoftLumixкакие потери мы несем при размещении условий выборок в джоин-секцииДля OUTER JOIN-ов - изменение логики (и результата) запроса.

Можете привести какой-нибудь пример на пальцах?
Вот тут по-вашему логика меняется или нет?




miksoftLumixкакие потери мы несем при размещении условий выборок в джоин-секцииДля INNER JOIN-ов - затруднение сопровождаемости.

А это что имеется ввиду?
Можете какой-нибудь пример на пальцах?

miksoftLumixМожете привести какой-нибудь пример на пальцах?
Вот тут по-вашему логика меняется или нет?


Да, конечно, меняется. Тут условие where b.tit = 'some' фактически превращает left join в просто join.

Oк, согласен.
А как насчет такого?




или вы хотите сказать, что как только мускул увидит условие a.tit = 'some', то он тут же сам включит inner??

miksoftLumixпропущено...


А это что имеется ввиду?
Можете какой-нибудь пример на пальцах?Другой разработчик, который потом будет читать этот запрос, имеет все основания полагать, что в секции WHERE он увидит все условия для фильтрации. И он не будет ожидать, что часть из них спряталась в секции FROM. Если это запрос строк эдак на 200, то это становится проблемой. А я и в пяти строчках могу ошибиться таким образом :)

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

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

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

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

PS. В наших проектах не существует запросов на 200 строк.
Просто архитектура платформы так устроена, что подобные запросы физически никогда не требуются.
К тому же наши разработчики практически не лазят в sql...
Очень-очень редко, когда дело доходит до живого sql...
Это очень-очень редко...

miksoftLumixА как насчет такого?


Эти запросы логически эквивалентны.
Хотя второй из них имеет настолько непривычный вид, что вызывает отторжение.
Lumixили вы хотите сказать, что как только мускул увидит условие a.tit = 'some', то он тут же сам включит inner??Нет, это только для "необязательной" стороны JOIN-а.

Ну вот, получается что вывод по этому пункту такой: я не вижу "криминала" в использовании условий в join-секции...

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

Читают они, читают.
И платформа позволяет творить любые чудеса с чистым sql.
Просто реально за много лет до сих пор не было ничего на 200 строк
И много лет уже пользуемся простановкой условий в джоин-секции и пока "никто не умер"))

http://www.codersrevolution.com/blog/MySQL-performance-INNER-JOIN-vs-subselect

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

miksoft, ok!

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