Всем привет!

Нужно соединить три таблицы. Хотел спросить, что использовать лучше:


или


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

И еще вопрос: второй способ - это какой джоин?

Заранее благодарен!

Это сообщение отредактировал(а) Acuna - 5.11.2013, 12:36

inner

то, что соответствует поставленной задаче


Надеюсь - перекрестился?

Это сообщение отредактировал(а) Zloxa - 5.11.2013, 13:05

Метко петросянить приятно... Наверное... Сам тоже люблю потроллить иногда, но к месту.


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

Это сообщение отредактировал(а) Acuna - 5.11.2013, 14:42

Приятного в этом мало. Куда приятнее дать развернутый ответ по существу на по существу сформулированный вопрос. На идиотские же сентенции отвечать идиотскими репликами удовольствия мало 

Добавлено через 1 минуту и 37 секунд

могут. Но не должны

Если вместо праздного вопрошательства почитать документацию (Раздел с названием типа "Как МуСКЛ оптимизирует джойны"), нетрудно понять, что разбор запроса первого типа состоит из его трансформации во второй тип плюс формирование довеска. 
И сразу станет понятно, что второй запрос может быть медленнее только в случае, когда для общей части для запросов будут построены разные планы выполнения, причём для второго запроса план будет построен ну очень неудачный. 
Теоретически, конечно, возможно - не зря есть соотв. хинты. Но весьма маловероятно.

Звучит странно. Можешь рефнуть?


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


Это сообщение отредактировал(а) Zloxa - 5.11.2013, 15:06

Могу. http://dev.mysql.com/doc/refman/5.5/en/sel...timization.html 
Читать только много, и в общем это всё слегка размазано. Основное - в http://dev.mysql.com/doc/refman/5.5/en/sel...timization.html

и в http://dev.mysql.com/doc/refman/5.5/en/lef...timization.html
========================================

На самом деле я рассматривал не запросы из исходного постинга (это бессмысленно, они неэквивалентны), а вариант первого запроса с внутренним связыванием - в этом случае запрос с inner join первым делом будет трансформирован в запрос с картезианкой и пачкой where, либо наоборот - вариант второго запроса с соответствующим довеском where x.some_field is null, в который опять-таки будет трансформирован первый запрос.

Ремарка насчёт выбора лидирующей таблицы совершенно правильна, однако то, что вариант с лидирующей второй таблицей при обработке where t1.f1=t2.f2 or t2.f2 is null может оказаться эффективнее, мне кажется сомнительным. Также мне кажется сомнительным весьма существование статистики, при которой оптимизатор в таком запросе решится сделать лидирующей вторую таблицу - во всяком случае, даже если такое возможно, всё равно у маси оптимизатор вовсе не блещет гениальностью и достаточно консервативен.

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



это ж все равно не экивавалент левому джойну.

в смысле "select a left join b on b.val=a.val" не эквивалентен "select a,b where b.val=a.val or b.val is null", внешнее соединение через внутреннее не выражается. 

Не знаю как в масе, в оракле есть такое понятие как old style join notation. Там джойны описываются в where кляузе, внешние помечаются символом "(+)" и для предикатов вводятся понятия пре-джойн предикат и пост-джойн предикат, которые тоже помечается символом "(+)". Оракл частенько(если не сказать "как правило") трансвформирует ANSIшную нотацию в свою old-style. Возможно и в масе есть нечто подобное и ты имеешь это в виду. Но и там ведь внешнее соединение остается внешним, через внутреннее оно нуникак не выражается. 


Это сообщение отредактировал(а) Zloxa - 5.11.2013, 18:16

Я вас понял) Просто я хотел максимально передать суть, а не пускаться в пространные размышления о выборе БД, смысла жизни и теориях создания мира (хотя по-поводу последнего я бы пообщался).

В первом посте забыл описать проблему, которая заключается в вот, что скрипты вдруг начали выполняться секунд на 10 медленнее. Оказалось, что это просто совпало с тем, что я переписал запросы с LEFT на INNER.

Спасибо, почитал тему с великим удовольствием!

Это сообщение отредактировал(а) Acuna - 6.11.2013, 16:32