Какой тип JOIN используется по умолчанию при написании просто JOIN

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

Базовое знание SQL и то, насколько внимательно вы читаете чужие запросы. Для тестировщика это не теория: INNER JOIN в проверочном запросе молча прячет записи без пары, и баг проходит мимо. Следом часто спрашивают, сколько строк вернёт запрос на конкретных данных.

Как отвечать

Просто JOIN по стандарту SQL означает INNER JOIN: в результат попадают только строки, для которых нашлась пара по условию ON. Слово INNER необязательно, так же как OUTER в LEFT OUTER JOIN.

Дальше покажите, что понимаете следствия:

• строки без пары пропадают: заказ с удалённым пользователем или с NULL в ключе в выборку не попадёт, потому что NULL не равен ничему, даже другому NULL;
• строки размножаются: при связи «один ко многим» пользователь с тремя заказами даст три строки, и COUNT(*) покажет не число пользователей;
• есть особенности диалектов: в MySQL JOIN без ON работает как CROSS JOIN и возвращает декартово произведение, а PostgreSQL на такой запрос выдаст синтаксическую ошибку;
• запятая в FROM: с условием в WHERE даёт тот же результат, что внутреннее соединение, но условие легко забыть.

Как это всплывает в тестировании: вы сверяете количество заказов в интерфейсе с базой, пишете JOIN к пользователям и получаете меньше, чем в UI. Это не баг интерфейса, а свойство запроса. Для поиска записей без пары нужен LEFT JOIN с проверкой IS NULL по ключу правой таблицы.

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

Отвечают «по умолчанию LEFT JOIN» или «зависит от базы». Во всех распространённых СУБД JOIN с условием ON это внутреннее соединение.

Путают NATURAL JOIN с обычным. Он соединяет по всем одноимённым колонкам, и если в обеих таблицах есть created_at, условие соединения окажется совсем не тем, что вы ждали.

Не проверяют результат на дубли. В тест-кейсе ожидают одну строку на пользователя, получают три и заводят ложный дефект, вместо того чтобы посмотреть на кратность связи.