SQL может быть синтаксически идеальным и всё равно врать в метриках. Ревью это часто не ловит.

Типичная картина: запрос “логичный”, имена понятные, всё читабельно. А в отчёте внезапно выросли конверсии, упала выручка, “сломалась воронка”. Начинаются обсуждения продукта, хотя проблема в том, что данные посчитаны не теми строками и не в тех границах времени.

Почему так происходит: SQL легко выдаёт правдоподобный результат даже когда нарушена кардинальность, фильтр применён не на той стороне join, NULL тихо выключил часть условий, оконная функция посчитала “не то окно”, а временная зона сдвинула сутки. На глаз это выглядит корректно, пока не сделаешь несколько проверок на инварианты.

Минимальный self-checklist перед продом/отчётом:

  1. Join-умножения: для каждого join проговори ожидаемую кратность (1 к 1, 1 к N). Проверь уникальность ключей в присоединяемой таблице и посмотри, как меняется число строк после join. Если строк стало больше “вдруг” — ты уже считаешь другой мир.

  2. WHERE против ON: фильтры для таблицы справа в LEFT JOIN держи в ON, иначе незаметно превратишь left в inner и потеряешь “пустых” пользователей/сессии. В WHERE оставляй то, что действительно должно отрезать строки результата.

  3. NULL-логика: NOT IN и сравнения с NULL дают сюрпризы. Явно решай, как трактуются пропуски: сохраняем, исключаем, или маппим в значение через COALESCE. Любое условие с “не равно” без мысли о NULL — красный флаг.

  4. Оконные функции: проверь PARTITION BY и ORDER BY, и что порядок детерминированный. Подумай про рамку окна: “по умолчанию” легко превращает кумулятив в не то, что ожидали. Если есть дубли по времени — добавь вторичный ключ в сортировку, иначе “первый” и “последний” плавают.

  5. Время и границы интервалов: зафиксируй таймзону, и используй один стиль границ (старт включительно, конец не включительно). Большая часть багов “за вчера” — это смещение по зоне или двойной учёт на границе дня.

Правильная практика выглядит скучно: после запроса ты можешь быстро объяснить кратность, что будет с NULL, почему окно именно такое, и почему сутки не поплывут. В ad-hoc исследовании можно жить рискованнее, но в дашбордах и метриках для решений этот чек-лист должен быть обязательным минимумом.