Работали ли вы с джойнами в базах данных

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

Дойдёте ли вы до данных самостоятельно, не дёргая разработчика, и понимаете ли, как соединение таблиц меняет количество строк. Для тестировщика джойн это инструмент проверки: сверить то, что показывает интерфейс, с тем, что лежит в базе.

Как отвечать

Перечислите типы и сразу привяжите к задаче: inner оставляет только совпавшие пары, left сохраняет все строки левой таблицы и подставляет null вместо отсутствующих, right симметричен ему, full объединяет обе стороны, cross даёт все комбинации. Самый полезный для проверок приём это поиск потерянных связей:

select o.id
from orders o
left join customers c on c.id = o.customer_id
where c.id is null;

Такой запрос находит заказы без клиента, то есть готовый дефект целостности. Дальше скажите, зачем вы это делаете: сверка витрины с источником, подготовка тестовых данных, проверка отчёта на задвоение. И обязательно про размножение строк: связь один ко многим увеличивает результат, поэтому после соединения count(*) считает пары, а не заказы, и нужен count(distinct o.id).

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

Переносят условие из on в where. Фильтр по правой таблице после внешнего соединения отбрасывает строки с null и молча превращает left join во внутренний, а тест при этом остаётся зелёным.

Не замечают дублей. После соединения с таблицей позиций сумма по заказу считается столько раз, сколько там позиций, и отчёт завышает выручку. Проверять надо количество строк до и после соединения.

Считают синтаксис одинаковым везде. Полного внешнего соединения в MySQL нет, его собирают объединением двух запросов, а сравнение null в условии не даёт совпадения, поэтому соединять таблицы по колонке с пустыми значениями бесполезно.