В users 5 млн строк; каждому юзеру нужен счётчик его заказов. Коллега вложил коррелированный COUNT-подзапрос прямо в SELECT. Чем это грозит на таком объёме и что проверишь, прежде чем переписывать на JOIN?
SQLmediummiddle
Проверяет владение SQL: выборки, агрегации, JOIN-ы и оконные функции.
собеседованиеsqlподзапросjoinоптимизация
Варианты ответа
Ничем: PostgreSQL гарантированно превращает коррелированный подзапрос в hash join, план совпадёт с JOIN + GROUP BY
Подзапрос логически выполняется на каждую строку users — «запрос в цикле»; смотрю EXPLAIN: оптимизатор иногда сам делает join
JOIN тут не подойдёт: агрегат по связанной таблице несовместим с GROUP BY по users — остаётся подзапрос плюс индекс
Грозит неверным результатом: скалярный подзапрос потеряет юзеров без заказов, а LEFT JOIN с COUNT их сохранит
Как разобрать этот вопрос на собеседовании
Начни с разбора схемы: какие таблицы и ключи участвуют, где могут быть NULL и дубли строк. Затем реши, что важнее — JOIN, агрегация с GROUP BY/HAVING, оконная функция или подзапрос. На собеседовании ценят не только правильный результат, но и умение проговорить план запроса и крайние случаи (пустые группы, деление на ноль, фан-аут при JOIN).
На собеседовании по такому вопросу важно не только назвать ответ, но и кратко объяснить, почему он верный.
Тема вопроса — «SQL». Чтобы подготовиться к похожим задачам, отрабатывай их на практике: sql-тренажёр помогает довести навык до автоматизма, а раздел вопросов — увидеть формулировки, которые реально встречаются на интервью аналитика данных.
Разбор ответа
Подробный разбор с объяснением «почему правильный ответ верный» и почему остальные неверны — после регистрации.
3000+ вопросов с разбором, quiz-режим с проверкой, AI-собес и подготовка к интервью аналитика.