Оптимален ли такой JOIN запрос?

Question

[Павел]

Всем привет. Имею такую структуру БД:

T1
id

T2
id

T3
id
t2_id
t1_id

Нужно написать такой запрос, что бы выбрать из таблицы T2 все записи, для которых есть связанная запись в T3. Выбрать нужно по id из T1.
Ну то есть, нужны все T2, для которых существуют записи из T3 по id из T1.

Написал такой JOIN

select "T2".* from "T2" inner join "T3" on "T3"."t2_id" = "T2"."id" WHERE "T3"."t1_id" " = ?

Я получаю, что хочу. но правильно ли я понимаю, что при таком запросе сначала все равно выбираются все записи через JOIN, а потом уже по ним делается WHERE ? Или если будет LIMIT, например 100, то можно не переживать за нагрузку? И нужно ли как-то делать JOIN из 3 таблиц?

P.S. если плохо объяснил, можно, например, так объяснить задачу. Есть юзеры, продукты и заказы. Нужно выбрать все товары, которые покупал юзер.

Comments

[V Sh.]

Как составлена таблица Т3? Если вы ее составили по составному ключу (t1_id, t2_id) и включили каскадное удаление, то можете просто к этой таблице Т3 и обращаться.

[Павел]

V Sh., t1_id, t2_id - это внешние ключи. Отдельные. Каскадное удаление есть

[V Sh.]

Павел, а, неправильно посмотрел... Ну вот так побыстрее может будет работать. А может и также. В СУБД сейчас мощные оптимизаторы запросов стоят:

select "T2".* from "T2" inner join "T3" on "T3"."t2_id" = "T2"."id" AND "T3"."t1_id" " = ?

можно еще такой посмотреть по плану выполнения:

select "T2".* from "T2" 
WHERE "T2".id in (SELECT "T3"."t2_id" FROM "T3" WHERE "T3".t1_id = ?)

[Павел]

V Sh., спасибо, попробую

Answer 1

[terrier]

Посмотреть реальный порядок операций можно, использовав EXPLAIN - он зависит от решений принятых оптимизатором. Которые в свою очередь зависят от индексов размера данных и распределения данных и факторов специфичных для конкретной СУБД.

Comments

[Павел]

Если я правильно понял, то сначала был сделан JOIN 5 строк, потом WHERE - 2 строки

[terrier]

Не совсем.
EXPLAIN читается в некотором смысле "снизу вверх", то есть результаты операций с бОльшим отступом подаются на вход операциям с меньшим отступом.
Здесь у вас две "нижние" операции - это Seq Scan по таблице offers c фильтром по user_id = 12 и Materialize ( то есть как бы "загрузка в память" таблицы jobs).
После этого на них делается JOIN ( с применением алгоритма Nested Loop, как мы видим в верхней строке).

И, да, для того чтобы исполнить запрос и узнать что реально получилось нужно применять EXPLAIN ANALYZE - оптимизатор может и ошибаться по поводу оптимального плана

Answer 2

[d-stream]

Это очень сильно зависит от конкретной реализации парсера-оптимизатора запросов.

Но чисто сферически лесенка из пары-тройки inner join посильна любому оптимизатору.