Какое минимальное и максимальное количество строк можно получить при левом джойне двух таблиц с 10 и 50 строками

Что проверяют

Понимаете ли вы, что джойн может размножить строки, и замечаете ли это в данных. Для аналитика и ML-инженера это прямой путь к завышенной выручке или к дублям в обучающей выборке, поэтому следом часто спрашивают, как вы ловите такое размножение.

Как отвечать

Левая таблица 10 строк, правая 50:

• минимум 10: каждая левая строка попадает в результат хотя бы раз. Если пары нет, она придёт с NULL во всех колонках правой таблицы;
• максимум 500: каждая из 10 строк совпала со всеми 50, например у всех строк один и тот же ключ. Это 10 × 50, а не 10 + 50.

Реальное число между ними зависит от кратности связи. Если справа ключ уникален (справочник, связь «многие к одному»), будет ровно 10. Если справа по ключу несколько строк, каждая левая строка размножится на их число.

На практике это проверяют до и после джойна:

• уникальность ключа справа: SELECT key, COUNT(*) FROM b GROUP BY key HAVING COUNT(*) > 1;
• сравнение числа строк: COUNT(*) до и после джойна, при ожидаемой связи «многие к одному» они обязаны совпасть;
• контракт в pandas: df.merge(dim, on="key", how="left", validate="many_to_one") падает с ошибкой, если справа дубли;
• тесты в dbt: unique и not_null на ключе справочника.

В Spark к этому добавляется перекос: один горячий ключ с тысячами совпадений раздувает одну партицию, и вся задача ждёт последний таск.

Где спотыкаются

Называют максимум 60, складывая таблицы. Сложение даёт UNION ALL, а джойн перемножает совпадения.

Считают агрегаты после джойна со справочником, где ключ неожиданно не уникален. SUM(amount) по заказам после размножения вырастает в разы, и ошибку замечают только на сверке с финансами.

Ставят фильтр по правой таблице в WHERE. Строки без пары получают NULL, фильтр их отбрасывает, и минимум падает с 10 до нуля: левый джойн превратился во внутренний.