Ментальная модель SELECT: логический порядок обработки

Порядок, в котором пишешь — не порядок, в котором выполняется

Оператор SELECT пишется в одном порядке, а вычисляется в совершенно другом. Письменный порядок задан грамматикой — SELECT всегда идёт первым. Но логический порядок обработки (порядок, в котором по стандарту SQL клаузы концептуально вычисляются) ставит SELECT ближе к концу:

1. FROM (и JOIN) — построить рабочий набор строк из исходных таблиц.
2. WHERE — оставить только строки, где предикат TRUE (это selection, отбор).
3. GROUP BY — схлопнуть выжившие строки в группы.
4. HAVING — оставить только группы, где предикат TRUE.
5. SELECT — вычислить выходные выражения и присвоить алиасы (это projection, проекция).
6. DISTINCT — убрать дублирующиеся выходные строки.
7. ORDER BY — отсортировать результат.
8. LIMIT / OFFSET — отрезать кусок отсортированного результата.

Восемь шагов складываются в конвейер: шаги 1–4 решают, какие строки и группы выживут, шаг 5 решает, как выглядит каждая выходная строка, а шаги 6–8 формируют финальную презентацию. Без этого порядка в голове ошибки видимости алиасов и сюрпризы производительности выглядят как причуды Postgres — но это не так.

Это логическая модель: исполнитель не материализует буквально полный набор после каждого шага (он стримит, а планировщик переупорядочивает ради скорости — это конвейер из прошлого урока и глава execution-plans трека databases). Но правила разрешения имён, которые ты можешь наблюдать, следуют этому порядку точно, и именно это людей и кусает.

Проекция против отбора: две разные работы

Два слова из реляционной алгебры снимают бо́льшую часть путаницы:

• Selection (отбор) = выбор строк. Это WHERE (и HAVING для групп). Отвечает на «какие строки выживут?».
• Projection (проекция) = выбор и вычисление колонок. Это SELECT. Отвечает на «как выглядит каждая выходная строка?».

Это отдельные стадии. WHERE бежит на шаге 2 на сырых колонках таблицы; SELECT бежит на шаге 5 и является единственным местом, где рождаются алиасы выходных колонок.

-- orders(id, user_id, price, qty, status, created_at)
SELECT
  user_id,
  price * qty AS revenue          -- 'revenue' рождается ЗДЕСЬ, на шаге 5
FROM orders                       -- шаг 1
WHERE status = 'paid'             -- шаг 2: 'revenue' ещё не существует
ORDER BY revenue DESC             -- шаг 7: 'revenue' уже существует
LIMIT 20;                         -- шаг 8

Почему алиас работает в ORDER BY, но не в WHERE

Теперь противоречие из вступления растворяется. WHERE — это шаг 2; алиас revenue из SELECT не создаётся до шага 5. Значит, ссылка на него в WHERE — это ошибка путешествия во времени: ты именуешь то, чего ещё нет. Postgres отвергает запрос с column "revenue" does not exist.

ORDER BY — это шаг 7, после SELECT. К этому моменту алиас уже существует, поэтому ORDER BY revenue разрешается чисто. ORDER BY — единственная клауза, которая видит имена выхода SELECT, именно потому что бежит после проекции.

Фикс для случая с WHERE — повторить выражение (под хорошим планом движок всё равно вычислит его один раз) или обернуть запрос в подзапрос / CTE, чтобы алиас материализовался на внутреннем шаге:

-- Вариант A: повторить выражение в WHERE (оно ссылается на базовые колонки, всегда легально)
SELECT user_id, price * qty AS revenue
FROM orders
WHERE status = 'paid' AND price * qty > 100;

-- Вариант B: назвать один раз во внутреннем запросе, фильтровать во внешнем (алиас теперь виден)
SELECT * FROM (
  SELECT user_id, price * qty AS revenue
  FROM orders WHERE status = 'paid'
) s
WHERE s.revenue > 100;

Колонка против выражения на выходе, и одна продакшен-ловушка

Каждый элемент списка SELECT — это либо голая колонка (user_id), либо вычисляемое выражение (price * qty, lower(email), count(*)). Голая колонка без алиаса сохраняет своё имя; выражение без алиаса получает уродливое авто-имя вроде ?column?. Всегда давай алиас выражениям — нижестоящий код, BI-инструменты и ORDER BY ключуются по этому имени.

Продакшен-ловушка, прямо вытекающая из порядка обработки: перенос тяжёлой логики в SELECT не уменьшает число сканируемых строк. WHERE уже отработал. Если твой SELECT зовёт дорогую функцию на строку, а WHERE неселективен, ты всё равно платишь за эту функцию на каждой выжившей строке. Фильтрация — рычаг для скольких строк; проекция лишь формирует что показывает каждая строка. Однажды команда перенесла медленный regex в SELECT, думая, что он «будет работать меньше» — он отработал на всех 4 миллионах выживших строк ровно как раньше, потому что WHERE не изменился. Селективность живёт в WHERE, а не в SELECT.