Какие конструкции в SQL вы избегаете или используете чаще?

Что проверяют

Пишете ли вы запросы осознанно: какие конструкции дают неверный результат, а какие просто медленные. Вопрос звучит как про вкусы, но следом просят объяснить конкретный пункт, например почему опасен NOT IN.

Как отвечать

Разделите ответ на две части и у каждого пункта называйте причину.

Чего избегаете:

• *`SELECT `** в отчётах: запрос ломается при изменении схемы, а в колоночных базах вроде ClickHouse читает все столбцы;
• NOT IN с подзапросом: один NULL в подзапросе даёт пустой результат. Надёжнее NOT EXISTS;
• функции над колонкой в WHERE: date(created_at) = '2026-09-01' не использует индекс, лучше диапазон created_at >= ... AND created_at < ...;
• DISTINCT от дублей: дубли обычно значат неверный ключ соединения, их надо найти, а не спрятать;
• UNION вместо UNION ALL: лишняя дедупликация там, где дублей нет;
• BETWEEN для дат со временем: верхняя граница '2026-09-30' теряет весь последний день после полуночи.

Что используете часто:

• CTE (WITH): запрос читается по шагам. В PostgreSQL с 12-й версии CTE, на который ссылаются один раз, встраивается в запрос и не мешает оптимизатору;
• оконные функции: ранги, нарастающие итоги, сравнение с прошлым периодом без самосоединений;
• условная агрегация: SUM(CASE WHEN ... THEN 1 ELSE 0 END) или COUNT(*) FILTER (WHERE ...) в PostgreSQL, несколько метрик за один проход;
• COALESCE для пропусков и явные JOIN вместо таблиц через запятую.

Где спотыкаются

Говорят «подзапросы всегда медленнее JOIN». Оптимизаторы часто переписывают их одинаково, решать нужно по плану запроса.

Пишут LEFT JOIN, а условие на правую таблицу ставят в WHERE. Строки без пары отсекаются, и соединение фактически становится внутренним.

Называют индексы конструкцией SQL. Для аналитика это сигнал, что разница между запросом и физической структурой базы не очень ясна.