Антипаттерн: использование SELECT * в продакшене
Кажется безобидным, правда? Особенно на этапе прототипирования. Но как только ваш запрос с SELECT * уходит в прод, начинаются проблемы:
Почему это плохо:
– Избыточные данные. Вы тянете всё, включая ненужные поля. Это бьёт по сети, памяти и CPU.
– Ломкость кода. Добавили колонку в таблицу — и, внезапно, старый код падает, потому что ожидал другую структуру.
– Плохая читаемость. Непонятно, какие поля реально нужны. Это мешает отладке и сопровождению.
– Невозможно использовать covering index — индекс по нужным колонкам не спасёт, если вы вытаскиваете всё подряд.
Как правильно:
Явно указывайте нужные поля:
Работаете с ORM — настраивайте выборку полей в select() или .only() (в зависимости от фреймворка).
В аналитике? Даже при джойнах и CTE — указывайте, что реально используете.
Запомни: чем меньше данных ты запрашиваешь — тем быстрее и стабильнее работает твой код.
Кажется безобидным, правда? Особенно на этапе прототипирования. Но как только ваш запрос с SELECT * уходит в прод, начинаются проблемы:
Почему это плохо:
– Избыточные данные. Вы тянете всё, включая ненужные поля. Это бьёт по сети, памяти и CPU.
– Ломкость кода. Добавили колонку в таблицу — и, внезапно, старый код падает, потому что ожидал другую структуру.
– Плохая читаемость. Непонятно, какие поля реально нужны. Это мешает отладке и сопровождению.
– Невозможно использовать covering index — индекс по нужным колонкам не спасёт, если вы вытаскиваете всё подряд.
Как правильно:
Явно указывайте нужные поля:
SQL:
SELECT id, name, created_at FROM users;Работаете с ORM — настраивайте выборку полей в select() или .only() (в зависимости от фреймворка).
В аналитике? Даже при джойнах и CTE — указывайте, что реально используете.
Запомни: чем меньше данных ты запрашиваешь — тем быстрее и стабильнее работает твой код.
