SQL ломается не на запросах, а на плохих привычках в схеме и фильтрах

SQL ломается не на запросах, а на плохих привычках в схеме и фильтрах

Почти любой медленный или хрупкий SQL начинается одинаково:
— выбирают * вместо нужных полей;
— фильтруют по выражению, которое не использует индекс;
— пишут JOIN без явного ключа и потом лечат дубликаты;
— забывают, что NULL и пустая строка — не одно и то же.

Если запрос должен быть быстрым, сначала проверь: есть ли индекс под WHERE и JOIN, не оборачиваешь ли колонку функцией, нет ли лишней сортировки и не тянется ли большой набор строк ради пары значений. В postgres часто выигрывает не “магия”, а простая дисциплина в форме запроса.

Для поддержки читаемости держи правило: один запрос — одна задача. Если нужно посчитать, отфильтровать и обогатить данные, лучше собрать это через CTE или отдельные шаги, чем прятать логику в один длинный блок. Так проще ревьюить, проще искать узкие места и проще объяснять поведение auth- и rls-логики, когда SQL работает рядом с политиками.

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