Фильтрация строк: WHERE, приоритет операторов и sargability

Приоритет: AND связывает крепче, чем OR

WHERE вычисляет булево выражение на строку. Ловушка — в приоритете: AND связывает крепче, чем OR, ровно как * крепче +. Поэтому это:

SELECT * FROM orders
WHERE status = 'paid' OR status = 'shipped' AND total > 100;

не значит «(paid или shipped) и total больше 100». Это значит status = 'paid' OR (status = 'shipped' AND total > 100) — каждый оплаченный заказ возвращается независимо от total, чего почти никогда не имели в виду. Фикс механический и неоспоримый на ревью: скобки на любой смешанный AND/OR.

SELECT * FROM orders
WHERE (status = 'paid' OR status = 'shipped') AND total > 100;

NOT связывает крепче всех троих. Когда мешаешь все три, безопасная привычка: никогда не доверяй приоритету, всегда группируй скобками. Баг приоритета не падает с ошибкой — он молча возвращает неверные строки, а это худший вид багов.

Удобные предикаты: BETWEEN, IN, LIKE/ILIKE

• BETWEEN a AND b включает оба конца: total BETWEEN 100 AND 200 — это total >= 100 AND total <= 200. Классическая ошибка — BETWEEN на timestamp: created_at BETWEEN '2026-01-01' AND '2026-01-31' исключает почти весь 31 января, потому что верхняя граница — полночь. Для диапазонов времени предпочитай полуоткрытый интервал: created_at >= '2026-01-01' AND created_at < '2026-02-01'.
• IN (…) — аккуратная цепочка OR: status IN ('paid','shipped'). (IN с подзапросом и NULL имеет знаменитую ловушку — это следующий урок.)
• LIKE делает сопоставление по шаблону: % = любая последовательность символов, _ = один символ. ILIKE — версия без учёта регистра (расширение Postgres).

-- users(id, email, display_name, created_at)
SELECT id, email FROM users
WHERE email LIKE 'support@%'              -- закреплённый префикс: дружелюбен к индексу
  AND created_at >= '2026-01-01'
  AND created_at <  '2026-02-01';         -- полуоткрытый диапазон, без ловушки BETWEEN

Sargability: слово, объясняющее зазор в 900×

Предикат sargable (Search-ARGument-able), если планировщик может использовать его для работы с индексом вместо скана каждой строки. Правило большого пальца: индексируемая колонка должна стоять голой с одной стороны, сравниваясь с константой. Как только ты оборачиваешь колонку в функцию или преобразуешь её, B-tree — отсортированный по сырым значениям колонки — становится бесполезен, потому что индекс понятия не имеет, как сортируется lower(email).

Два не-sargable паттерна доминируют в продакшен-инцидентах:

1. Функция на колонке. WHERE lower(email) = 'a@b.com' не может использовать индекс на email, потому что индекс хранит email, а не lower(email). Фикс — выражательный индекс (expression index) — индекс, покрывающий ровно то выражение, которое ты запрашиваешь: CREATE INDEX ON users (lower(email));. Теперь lower(email) = … снова sargable. (Внутренности индексов — B-tree, правило ведущей колонки, выражательные индексы — глубоко преподаёт глава indexes трека databases; здесь нужно лишь следствие формы предиката.)
2. Ведущий wildcard в LIKE. WHERE email LIKE 'abc%' sargable — префикс abc закрепляет непрерывный диапазон в отсортированном B-tree, и Postgres идёт прямо к нему. WHERE email LIKE '%abc' — нет: нет фиксированного префикса для поиска, так что каждое значение нужно проверить. Поиск с ведущим wildcard на масштабе требует другого инструмента (trigram GIN-индекс или full-text search, т.е. полнотекстовый поиск), а не B-tree.

Эти два паттерна вместе покрывают большинство багов «индекс есть, но не используется». Когда видишь медленный запрос, который должен быть быстрым, — первым делом проверь, стоит ли колонка голо в WHERE, прежде чем добавлять новые индексы.

Параметризуй — ради безопасности И ради переиспользования плана

Никогда не собирай значение WHERE склейкой пользовательского ввода. WHERE email = '" + input + "' — учебниковая дыра SQL-инъекции: ввод ' OR '1'='1 превращает твой фильтр в тавтологию, возвращающую всю таблицу. Фикс — параметризованные запросы (bind-параметры / prepared statements): значение едет отдельно от текста SQL, поэтому никогда не может изменить структуру запроса.

-- Параметризовано: плейсхолдер $1 привязывается к значению драйвером,
-- никогда не интерполируется в SQL-строку. Инъекция становится невозможной.
SELECT id, email FROM users WHERE email = $1;

Параметризация также позволяет Postgres кешировать и переиспользовать распарсенный/спланированный оператор между вызовами, убирая накладные расходы parse и plan на горячих путях. Безопасность и производительность указывают в одну сторону: привязывай, не склеивай.