Meistercheck: SELECT in Aktion
What you'll learn
- ein vollständiges
SELECTsicher zusammenzubauen: Spaltenauswahl, Aliasse,WHERE-Filter,BETWEEN/IN/LIKE, Sortierung mitLIMIT— anhand der Traineraufgaben - Ursachen unauffälliger Fehler zu finden: Vergleiche mit
NULL,ORohne Klammern,CASEohneELSE,LIMITohneORDER BY - Gewohnheiten für verlässliche Abfragen zu festigen: Klammern in gemischten Bedingungen, ein explizites
ELSE, eine Sortierung mit eindeutigem Schlüssel
Festigen wir SELECT an echten Aufgaben
QUERY dimmt die überflüssigen Panels. Im Saal bleiben ein Terminal und drei Aufgaben: die Prüfung für die erste Freigabe. Die Akademie vertraut keinen Worten — nur Abfragen.
Du hast dir das Handwerkszeug eines lesenden Archivars erarbeitet: Du wählst die nötigen Spalten aus, gibst ihnen verständliche Aliasse, filterst Zeilen über WHERE, gehst sorgsam mit NULL um, nutzt BETWEEN/IN/LIKE, legst die Reihenfolge über ORDER BY/LIMIT fest, entfernst Duplikate über DISTINCT und fügst einfache Logik über CASE hinzu.
Jetzt festige das mit den Aufgaben im Trainer: Sie ähneln gewöhnlichen Fragen an „Kotomarket“ — was angezeigt werden soll, was wegfällt und wie das Ergebnis zu beschriften ist. Löse sie im Editor (sie öffnen sich in einem neuen Tab), und der Block unten wird als bestanden markiert.

Как читать полный SELECT
Когда запрос становится длиннее трёх строк, новичок часто теряется. Кажется, что SQL выполняется строго сверху вниз, как текст.
Но удобнее читать запрос по смысловым слоям.
Например:
SELECT
name,
category,
price,
CASE
WHEN price < 1500 THEN 'дешёвый'
WHEN price < 4000 THEN 'средний'
ELSE 'дорогой'
END AS segment
FROM products
WHERE category IN ('Книги', 'Игрушки')
AND price BETWEEN 1000 AND 3000
ORDER BY price DESC, id
LIMIT 5;
Такой запрос можно разобрать по шагам.
Сначала источник:
FROM products
База берёт таблицу товаров.
Потом фильтр строк:
WHERE category IN ('Книги', 'Игрушки')
AND price BETWEEN 1000 AND 3000
Остаются только книги и игрушки с ценой от 1000 до 3000 включительно.
Потом список столбцов и вычислений:
SELECT
name,
category,
price,
CASE ... END AS segment
Запрос показывает название, категорию, цену и добавляет сегмент через CASE.
Потом порядок:
ORDER BY price DESC, id
Сначала дорогие товары, а при одинаковой цене — стабильная сортировка по id.
И только после этого ограничение:
LIMIT 5
Остаются первые пять строк уже после сортировки.
Главная мысль:
LIMITне выбирает «лучшие» строки сам. Он просто берёт верхушку того порядка, который ты задал черезORDER BY.
Что делает запрос надёжным
На этом уровне важно не просто получить зелёную галочку. Важно начать думать как человек, который понимает, почему запрос вернул именно эти строки.
Надёжный запрос обычно обладает тремя признаками.
Первый признак — он явно говорит, какие строки нужны.
Плохо, когда условие приходится угадывать по куску логики. Хорошо, когда WHERE читается как точное правило:
WHERE category IN ('Книги', 'Игрушки')
AND price BETWEEN 1000 AND 3000
Второй признак — он явно говорит, в каком порядке нужен результат.
Если важны самые дорогие товары, самые свежие заказы или первые пользователи по алфавиту, это должно быть записано в ORDER BY:
ORDER BY price DESC, id
Третий признак — он не прячет неопределённость.
Если в данных может быть NULL, запрос должен учитывать это явно:
WHERE city IS NULL
или:
WHERE city <> 'Москва'
OR city IS NULL
Если в CASE есть строки, которые не попали ни в одну ветку, лучше заранее решить, что с ними делать:
ELSE 'другой статус'
Если порядок при равных значениях важен, его нужно добить уникальным ключом:
ORDER BY price DESC, id
На маленьких учебных таблицах многие недочёты незаметны. Но в реальной базе такие мелочи превращаются в тихие ошибки: запрос выполняется без падения, но результат оказывается не тем.
Тихие ошибки: когда запрос работает, но врёт
Самые неприятные ошибки в SQL не всегда выглядят как красная ошибка синтаксиса.
Гораздо чаще запрос запускается, возвращает таблицу, но строки в ней не те.
Например, сравнение с NULL:
WHERE city = NULL
Синтаксически запрос может быть корректным, но он не найдёт строки, где города нет. Для NULL нужна проверка:
WHERE city IS NULL
Или условие со смешанными AND и OR:
WHERE category = 'Книги'
OR category = 'Игрушки'
AND price < 3000
Такой запрос читается глазами как:
книги или игрушки, и цена меньше 3000
Но SQL сначала связывает AND, а потом OR. Поэтому фактическая логика другая:
WHERE category = 'Книги'
OR (category = 'Игрушки' AND price < 3000)
Если тебе нужно применить цену к обеим категориям, нужны скобки:
WHERE (category = 'Книги' OR category = 'Игрушки')
AND price < 3000
Или так, ещё чище:
WHERE category IN ('Книги', 'Игрушки')
AND price < 3000
Ещё один тихий сбой — CASE без ELSE:
CASE
WHEN status = 'paid' THEN 'оплачен'
WHEN status = 'pending' THEN 'ожидает'
END AS status_label
Если появится статус cancelled, метка станет NULL. Иногда это нормально, но чаще для отчёта лучше явно написать запасной вариант:
ELSE 'другой статус'
И наконец, LIMIT без ORDER BY:
SELECT name, price
FROM products
LIMIT 5;
Этот запрос не выбирает топ-5. Он выбирает любые первые пять строк в том порядке, который база решила вернуть сейчас.
Для топа нужен критерий:
SELECT name, price
FROM products
ORDER BY price DESC, id
LIMIT 5;
Тихие ошибки опасны именно тем, что база не спорит. Она выполняет то, что написано. Даже если ты имел в виду другое.
КВЕРИ: Архив не читает намерения. Он читает запрос. Если мысль не записана явно, её не существует.
Перед отправкой запроса
Перед тем как отправить решение в тренажёре, полезно быстро пройтись по запросу глазами.
Сначала проверь, что ты выбрал ровно нужные столбцы.
Если в задаче просят:
name, price
не нужно оставлять:
SELECT *
Даже если так проще во время черновика, финальный ответ должен показывать то, что просит задача.
Потом проверь фильтр.
Если в условии задачи есть «от 1000 до 3000 включительно», хорошо подходит:
BETWEEN 1000 AND 3000
Если сказано «категория Книги или Игрушки», читаемее использовать:
IN ('Книги', 'Игрушки')
Если нужно «начинается с», подойдёт:
LIKE 'К%'
Если нужно «содержит», подойдёт:
LIKE '%К%'
Но помни: ведущий % может быть дорогим на больших таблицах.
Потом проверь NULL.
Если нужно найти отсутствующее значение, не пиши:
= NULL
Пиши:
IS NULL
Если нужно исключить значение, но сохранить строки с NULL, добавь это явно:
WHERE city <> 'Москва'
OR city IS NULL
Потом проверь сортировку.
Если в задаче есть слова:
самые дорогие
самые дешёвые
последние
первые
топ
почти наверняка нужен ORDER BY.
Если есть ограничение количества строк, почти наверняка нужен LIMIT.
И наконец, если сортируешь по столбцу, где возможны одинаковые значения, добавь уникальный ключ:
ORDER BY price DESC, id
Так результат будет стабильным.
Что ты уже умеешь к концу модуля
Этот модуль был про чтение строк.
Ты ещё не считаешь выручку, средний чек и количество заказов по группам — это следующий уровень. Но ты уже умеешь достать из таблицы именно тот слой данных, который нужен для ответа.
Тебе доступен базовый маршрут:
SELECT ...
FROM ...
WHERE ...
ORDER BY ...
LIMIT ...
Ты понимаешь, зачем нужны :
price * stock AS stock_value
Ты умеешь работать с отсутствующими значениями:
IS NULL
IS NOT NULL
COALESCE(...)
Ты умеешь задавать короткие фильтры:
BETWEEN
IN
LIKE
Ты умеешь получать словарь значений:
SELECT DISTINCT status
FROM orders;
Ты умеешь добавлять в выдачу человеческие метки:
CASE
WHEN ... THEN ...
ELSE ...
END
И главное — ты уже знаешь, что корректный синтаксис не гарантирует корректную мысль.
SQL может выполнить запрос идеально и всё равно вернуть не то, что ты хотел, если условие записано неточно.
Interview question
Frage aus dem Vorstellungsgespräch: Die Abfrage ist syntaktisch korrekt, doch Zeilen verschwinden „unbemerkt“ aus der Ausgabe oder erhalten falsche Werte. Nenne die typischen Ursachen.
Starke Antwort: Die vier klassischen Stolperfallen dieser Freigabestufe. (1) Vergleiche mit NULL: =, <> und NOT IN mit einer Liste, in der ein steckt, ergeben — die Zeile kommt nicht durch WHERE; Abhilfe schaffen IS NULL, IS DISTINCT FROM, COALESCE. (2) OR ohne Klammern: AND bindet stärker, und die Bedingung gruppiert sich anders, als sie sich liest. (3) CASE ohne ELSE liefert NULL für die nicht abgedeckten Zeilen, und WHEN NULL in der einfachen Form ist tot. (4) LIMIT ohne ORDER BY gibt „irgendwelche“ Zeilen zurück: Ohne Sortierung ist die Reihenfolge nicht garantiert. Im Vorstellungsgespräch zählt nicht die Liste, sondern die Gewohnheit: Klammern in gemischten Bedingungen, ein explizites ELSE, eine explizite Sortierung mit eindeutigem Schlüssel.
QUERY: From here the archive opens only to those who count. Revenue, average order value, groups — the next level of clearance.