| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > MySQL > Джоины или просто выборка |
| Автор: Acuna 5.11.2013, 12:31 | ||||
| Всем привет! Нужно соединить три таблицы. Хотел спросить, что использовать лучше:
или
Мне показалось, что во втором случае запросы стали выполняться заметно медленнее. И еще вопрос: второй способ - это какой джоин? Заранее благодарен! |
| Автор: Zloxa 5.11.2013, 13:02 | ||||||
inner
то, что соответствует поставленной задаче
Надеюсь - перекрестился? |
| Автор: Acuna 5.11.2013, 14:37 | ||
Метко петросянить приятно... Наверное... Сам тоже люблю потроллить иногда, но к месту.
Просто я параллельно занимаюсь доработкой и скриптов, и проблема может быть из-за скриптов, а не запросов. Вот я и спрашиваю, могут ли запросы второго способа работать медленнее? Во всяком случае, заметно медленнее. Если нет, то очевидно, что проблема не в них же) |
| Автор: Zloxa 5.11.2013, 14:43 | ||||
Приятного в этом мало. Куда приятнее дать развернутый ответ по существу на по существу сформулированный вопрос. На идиотские же сентенции отвечать идиотскими репликами удовольствия мало  Добавлено через 1 минуту и 37 секунд
могут. Но не должны |
| Автор: Akina 5.11.2013, 14:54 | ||
Если вместо праздного вопрошательства почитать документацию (Раздел с названием типа "Как МуСКЛ оптимизирует джойны"), нетрудно понять, что разбор запроса первого типа состоит из его трансформации во второй тип плюс формирование довеска. И сразу станет понятно, что второй запрос может быть медленнее только в случае, когда для общей части для запросов будут построены разные планы выполнения, причём для второго запроса план будет построен ну очень неудачный. Теоретически, конечно, возможно - не зря есть соотв. хинты. Но весьма маловероятно. |
| Автор: Zloxa 5.11.2013, 15:03 | ||||
Звучит странно. Можешь рефнуть?
Если бы речь шла не о масе, я бы предположил, что для первого запроса предопределена лидируюая таблица, для второго оптимизатор волен выбирать одну из трех, что существенно увеличивает вероятность того, что планы будут разными, правда это должно бы в первую очередь увеличивать вероятность выбора более удачного плана. |
| Автор: Akina 5.11.2013, 17:29 | ||||||
Могу. http://dev.mysql.com/doc/refman/5.5/en/select-optimization.html Читать только много, и в общем это всё слегка размазано. Основное - в http://dev.mysql.com/doc/refman/5.5/en/select-optimization.html
и в http://dev.mysql.com/doc/refman/5.5/en/left-join-optimization.html ========================================
На самом деле я рассматривал не запросы из исходного постинга (это бессмысленно, они неэквивалентны), а вариант первого запроса с внутренним связыванием - в этом случае запрос с inner join первым делом будет трансформирован в запрос с картезианкой и пачкой where, либо наоборот - вариант второго запроса с соответствующим довеском where x.some_field is null, в который опять-таки будет трансформирован первый запрос. Ремарка насчёт выбора лидирующей таблицы совершенно правильна, однако то, что вариант с лидирующей второй таблицей при обработке where t1.f1=t2.f2 or t2.f2 is null может оказаться эффективнее, мне кажется сомнительным. Также мне кажется сомнительным весьма существование статистики, при которой оптимизатор в таком запросе решится сделать лидирующей вторую таблицу - во всяком случае, даже если такое возможно, всё равно у маси оптимизатор вовсе не блещет гениальностью и достаточно консервативен. |
| Автор: Zloxa 5.11.2013, 18:01 | ||||
Ясно, в этом контексте твое высказывание мне перестало казаться странным  С другой стороны ТС заменил внешний джойн внутренним и просел, в этом контексте размышлять о разнице в планах внутренних соединений записанных в разных нотациях, мне в голову не пришло.
это ж все равно не экивавалент левому джойну. в смысле "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. Возможно и в масе есть нечто подобное и ты имеешь это в виду. Но и там ведь внешнее соединение остается внешним, через внутреннее оно нуникак не выражается.  |
| Автор: Acuna 6.11.2013, 16:29 | ||
Я вас понял) Просто я хотел максимально передать суть, а не пускаться в пространные размышления о выборе БД, смысла жизни и теориях создания мира (хотя по-поводу последнего я бы пообщался). В первом посте забыл описать проблему, которая заключается в вот, что скрипты вдруг начали выполняться секунд на 10 медленнее. Оказалось, что это просто совпало с тем, что я переписал запросы с LEFT на INNER. Спасибо, почитал тему с великим удовольствием! |
