JOIN — это отфильтрованное произведение

Декартово произведение — это фундамент

На минуту забудь про «сопоставление». Базовейшая комбинация двух таблиц — это декартово произведение (CROSS JOIN): взять каждую строку users и спарить её с каждой строкой orders. Если в users 3 строки, а в orders 4, то в произведении ровно 3 × 4 = 12 строк. Никакого условия, никакого сопоставления — просто все возможные пары.

-- Сырое произведение: каждый пользователь с каждым заказом
SELECT u.id AS user_id, o.id AS order_id
FROM users u
CROSS JOIN orders o;
-- 3 пользователя × 4 заказа = 12 строк, неважно кто что заказал

Число строк произведения — |A| × |B|, оно умножается. Этот единственный факт и есть причина, по которой JOIN может взорваться. У двух таблиц по 100k строк произведение — 10 миллиардов строк. Движок никогда не материализует их все, если может избежать, но логический смысл твоего запроса всё равно — «начать с этого произведения». Когда видишь неожиданно большой результат, первый вопрос: где именно счётчик строк умножился?

INNER JOIN — это то же произведение, отфильтрованное

INNER JOIN ... ON <предикат> по определению — это декартово произведение с предикатом, применённым как фильтр. Эти два запроса логически тождественны:

-- В виде JOIN (так ты будешь писать всегда)
SELECT u.id, o.id, o.total
FROM users u
JOIN orders o ON o.user_id = u.id;

-- В виде произведение + фильтр (вот что это ЗНАЧИТ)
SELECT u.id, o.id, o.total
FROM users u
CROSS JOIN orders o
WHERE o.user_id = u.id;

Оба спрашивают: из всех 12 возможных пар оставить те, где o.user_id = u.id. Клауза ON — не особый синтаксис, а фильтр на произведении. Планировщик никогда не строит буквально сетку из 12 строк (он применяет hash, merge или nested-loop стратегии, чтобы дёшево прийти к тому же ответу — это урок про join-algorithms трека databases), но результат гарантированно равен «произведение, затем фильтр».

Эта переформулировка окупается сразу. Число строк на выходе INNER JOIN — это не |A| и не |B|. Это «сколько пар пережили фильтр», и зависит оно целиком от отношения. Если у каждого заказа ровно один совпадающий пользователь, в результате будет |orders| строк. Если ключ join неуникален с обеих сторон, можно получить больше строк, чем в любой из таблиц — это fan-out, тема последнего урока этого раздела.

Почему поведение CROSS JOIN — это фича, а не только грабли

Инцидент из хука был случайным произведением: кто-то написал JOIN, забыл предикат ON (или написал ON true) и получил |A| × |B|. SQL тебя не останавливает, потому что произведение иногда — ровно то, что нужно: календарная сетка, матрица комбинаций «каждый товар × каждый размер», заполнение пропусков. Четвёртый урок разбирает осознанные cross join. Дисциплина: клауза ON, которая на самом деле не ограничивает отношение, — это молча произведение, а произведение двух больших таблиц — это авария.