Как ведет себя JOIN & WHERE?

Question

[synapse_people]

Здравствуйте
Допустим есть запрос условно:

select ... from t0
inner join t1 on t1.col1=t1.col0
inner join t2 on t2.col2=t1.col1
inner join tN on tN.col2=t2.col1
//ну вы поняли, каскадно джойнится таблица А ДАЛЕЕ ИДЕТ
WHERE t2.colN IS TRUE

Теперь вопрос,
сервер сначала сджойнит все данные всех таблиц t0 t1 t2 t...N ИЛИ он дойдет до джойна t2 и увидит строгое WHERE, которое связано с этой таблицей и выгребет только те строки, которые соответствуют и ON И WHERE?

То есть вопрос, сначала обрабатываются все JOIN-ON, а затем WHERE
или учитывается WHERE еще на этапе JOIN?
MYSQL последний, но интересно как на других базах тоже. Спасибо

Answer 1

[ayazer]

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

Comments

[synapse_people]

а это можно будет потом оптимизировать индексами или все равно будет лагать?

[ayazer]

synapse_people, на этот вопрос нельзя однозначно ответить. замедляют ли иннер джойны селекты? конечно замедляют. как и любые другие джойны. Да даже наличие индексов и внешних ключей замедляет работу базы. В принципе большое кол-во иннерджойнов может быть показателем что структуру таблиц по хорошему пересмотреть. но без конкретного примера это все гадание на кофейной гуще.
а так - все субд чертовски хорошо умеют пользоваться индексами. на моей памяти некорректное использование индексов я наблюдал только в какой-то (относительно) древней версии авроры на таблице с партициями. там было очень неравномерное распределение данных между партициями и аврора в какой-то момент переключалась на фуллсканы по партиции с десятками/сотнями миллионов записей. не помню точно, но вроде это случалось это раз в пару месяцев и лечилось перезагрузкой. И пофиксилось после обновления на актуальную версию. Но в целом даже если субд начнет использовать индекс не оптимально - всегда можно использовать хинты чтоб это поправить.

Answer 2

[Иван Сорокин]

Общая логика: сначала всё сджойнить, потом от фильтровать по where.
Можно указать условия из where в нужном join, тогда отбор значений будет до join.
Как-то так: on (t1.id=t2.id and <условие>)

Answer 3

[101-s]

хороший вопрос, заставил меня прочесть статью: https://bookflow.ru/10-prostyh-shagov-k-polnomu-po...
есть лексический порядок и есть логический
Мы пишем так:
SELECT [ DISTINCT ]
FROM
WHERE
GROUP BY
HAVING
UNION
ORDER BY

а логика такая:

FROM
WHERE
GROUP BY
HAVING
SELECT
DISTINCT
UNION
ORDER BY

Comments

[synapse_people]

это понятно) но где здесь ключевое. JOIN

[101-s]

дык там же пояснение в статье, и я так понял JOIN идет первым. Потому как можно написать FROM table1, table2 ...
но не рекомендуется

Answer 4

[Антон Шаманов]

если рассматривать на про уровне, то побные вещи вариантивны т.ч.фиксированного алгоритма нет.
explain и мануал в помощь.