Почему оператор SELECT * в SQL запросах считается плохой практикой?

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

Понимаете ли вы цену лишних колонок и, что важнее для Go, как звёздочка ломает код при изменении схемы. Вопрос простой, поэтому оценивают умение назвать главный довод и случаи, где звёздочка нормальна.

Как отвечать

Разложите на три довода. Первый, лишний ввод-вывод: строка тянется целиком, включая большое текстовое поле или jsonb, который в PostgreSQL хранится отдельно и будет разжат ради того, чтобы клиент его выбросил.

Второй, индексы. Запрос с явным списком колонок иногда выполняется только по индексу, а звёздочка вынуждает лезть в таблицу за каждой строкой, и покрывающий индекс перестаёт работать.

Третий и самый болезненный в Go: неявный контракт между запросом и кодом.

rows, err := db.QueryContext(ctx,
    `select id, email from users where is_active = true`)

rows.Scan привязан к числу и порядку колонок. Стоит кому-то добавить колонку миграцией, и код со звёздочкой падает в рантайме на несовпадении числа аргументов, причём падает после выката миграции, а не на тестах. Явный список делает выборку независимой от схемы, а по коду сразу видно, какие поля нужны.

Обязательно оговорите, где звёздочка уместна: разовый разбор данных руками, проверка через select exists, подзапросы, где колонки всё равно не читаются. И честно скажите, что на узкой таблице из трёх полей разницы в скорости не будет, аргумент не про микросекунды.

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

Сводят всё к производительности и вязнут на вопросе «а если нужны все колонки». Главный довод не скорость, а предсказуемость: запрос перестаёт зависеть от того, что завтра добавят в таблицу, и по тексту видно используемые поля.

Считают, что count(1) быстрее count(*). Планировщик их не различает, и звёздочка в count не означает чтения колонок вовсе. Заявление про разницу сразу показывает, что знание пришло из чужих советов, а не из плана запроса.

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