Основы SQL-запросов: вопросы для собеседования (часть 6)
SELECT, FROM, WHERE, ORDER BY, LIMIT — базовый синтаксис SQL, с которого начинается любое собеседование. Кажется простым, но интервьюеры проверяют порядок выполнения клауз, приоритет операторов и понимание DISTINCT. Твёрдое знание основ — фундамент, без которого сложные задачи не решить.
Вопросы 26–30 из 40
26Что можно корректно утверждать про результат запроса `SELECT user_id FROM users LIMIT 10`, если в нём нет `ORDER BY`?
AБез `ORDER BY` СУБД не гарантирует, какие именно `10` строк попадут в результат запроса
BВсегда вернутся `10` пользователей с самыми ранними значениями в столбце `created_at`
CВсегда вернутся `10` пользователей с самыми поздними значениями в столбце `created_at`
DЗапрос не выполнится: `LIMIT` нельзя использовать без указания `ORDER BY`
Ответ: Без сортировки порядок строк не определён, поэтому `LIMIT` ограничит «первые `N`» в произвольном порядке.
`LIMIT` сам по себе не выбирает «первые по времени» или «последние по идентификатору» — он просто берёт первые N строк из текущего результата. Без `ORDER BY` СУБД не обязана возвращать строки в одном и том же порядке, и результат может меняться от запуска к запуску. Поэтому в аналитических задачах вроде топ-N, постраничной выдачи или списков всегда задают явную сортировку. Запрос с `LIMIT` без сортировки не падает, но поведение становится недетерминированным.
Подробный разбор → 27Вы строите выдачу «последние заказы» и используете `LIMIT 50`. Поле `created_at` не уникально (много заказов в одну секунду). Какой `ORDER BY` лучше, чтобы порядок был детерминированным?
A`ORDER BY created_at DESC`
B`ORDER BY created_at DESC, order_id DESC`
C`ORDER BY order_id DESC, created_at DESC`
D`ORDER BY created_at ASC, order_id DESC`
Ответ: Если основной ключ сортировки не уникален, добавляйте второй (обычно уникальный) столбец как разрешитель ничьих.
При `ORDER BY created_at DESC` строки с одинаковым `created_at` могут возвращаться в разном порядке, а это влияет на `LIMIT` и пагинацию. Добавив второй столбец, который однозначно различает строки (например, `order_id`), вы фиксируете порядок: `ORDER BY created_at DESC, order_id DESC`. Тогда «верхние 50» будут воспроизводимыми при повторных запросах к тем же данным. Обратный порядок ключей или сортировка по возрастанию времени дадут не тот результат, который вы хотите.
Подробный разбор → 28Что вернёт запрос `SELECT COUNT(DISTINCT user_id) FROM orders`, если у некоторых пользователей несколько заказов?
AЗапрос вернёт общее количество строк в таблице `orders` без какой-либо дедупликации значений
BЗапрос вернёт количество строк, где `user_id IS NOT NULL`, включая повторяющиеся значения столбца
CЗапрос вернёт количество уникальных значений `user_id`, пропуская `NULL` и дубликаты
DЗапрос вернёт ошибку, потому что `DISTINCT` нельзя использовать внутри агрегатной функции
Ответ: `COUNT(DISTINCT столбец)` считает количество уникальных непустых значений в указанном столбце.
Конструкция `COUNT(DISTINCT user_id)` сначала убирает дубликаты и `NULL` из значений `user_id`, а затем считает оставшиеся уникальные значения. Если в таблице 1000 заказов от 300 разных пользователей — результат будет 300, а не 1000. Это стандартный способ подсчёта уникальных сущностей: уникальных покупателей, товаров, посетителей. Использование `DISTINCT` внутри `COUNT` поддерживается во всех основных СУБД и не вызывает ошибки.
Подробный разбор → 29Первый `SELECT` возвращает два столбца `name, email`, а второй — три столбца `name, email, phone`. Что произойдёт при `SELECT name, email FROM users UNION ALL SELECT name, email, phone FROM contacts`?
AЗапрос вернёт ошибку: для `UNION ALL` количество и типы столбцов в обоих `SELECT` должны совпадать, иначе совместить наборы нельзя
BЗапрос выполнится успешно: лишние столбцы второго `SELECT` будут автоматически обрезаны до количества столбцов первого запроса
CЗапрос выполнится успешно: недостающие столбцы первого `SELECT` будут заполнены значением `NULL` для совместимости со вторым
DЗапрос объединит все столбцы из обоих `SELECT` в один широкий результат, добавив отсутствующие как `NULL` в каждой строке
Ответ: Для `UNION` и `UNION ALL` число и типы столбцов должны совпадать во всех объединяемых запросах, иначе будет ошибка.
SQL требует одинаковое количество столбцов с совместимыми типами во всех частях `UNION`. Если первый `SELECT` возвращает 2 столбца, а второй — 3, запрос завершится ошибкой и автоматического дополнения или обрезки не произойдёт. Чтобы это исправить, нужно либо убрать лишний столбец из второго запроса, либо добавить `NULL AS phone` в первый.
Подробный разбор → 30В таблице `imports` столбец `amount_text` хранит числа в текстовом виде (`"100.50"`, `"200"`). Что произойдёт при выполнении `SELECT CAST(amount_text AS NUMERIC) FROM imports`, если часть значений содержит буквы (`"N/A"`)?
AЗапрос вернёт `NULL` для строк с буквами, а корректные числа преобразует в `NUMERIC` без проблем
BЗапрос вернёт `0` для нечисловых строк, потому что `CAST` подставляет ноль вместо ошибочных значений
CЗапрос завершится ошибкой на первой же строке, где значение нельзя интерпретировать как число
DЗапрос пропустит проблемные строки и вернёт результат только по тем, что успешно преобразовались
Ответ: `CAST` выполняет строгое преобразование и падает с ошибкой, если значение нельзя интерпретировать как требуемый тип.
Конструкция `CAST(value AS type)` пытается строго преобразовать каждое значение в указанный тип. Для строк вроде `"100.50"` преобразование в `NUMERIC` пройдёт успешно. Но если встретится значение `"N/A"`, которое нельзя интерпретировать как число, запрос завершится ошибкой и не вернёт ни одной строки. Для безопасного приведения в PostgreSQL пишут `CASE WHEN ... THEN CAST(...)` или используют функции вроде `to_number` с проверкой формата.
Подробный разбор →