Regra
Evitar SELECCIONAR * em SQL queries.
SELECT * em produção código produz aplicações
frágeis para esquema alterações e obscurece dados dependências.

Idiomas suportados: 45+

Introdução

Utilizando SELECT * em queries de produção recupera todas as colunas de uma tabela, incluindo colunas que sua aplicação não usa. Quando esquemas de banco de dados evoluem e novas colunas são adicionadas (incluindo dados sensíveis como senhas ou PII), queries usando SELECT * comece a recuperá-los automaticamente sem alterações no código. Isso cria vulnerabilidades de segurança e quebra suposições na lógica da sua aplicação.

Por que isso importa

Impacto no desempenho: A recuperação de colunas desnecessárias aumenta o tempo de execução da query, o tamanho da transferência de rede e o consumo de memória. Uma tabela com 50 colunas onde você precisa apenas de 5 significa que você está transferindo 10 vezes mais dados do que o necessário, degradando os tempos de resposta e aumentando os custos de infraestrutura.

Implicações de segurança: Novas colunas adicionadas a tabelas (campos de auditoria, flags internas, dados sensíveis de usuários) são automaticamente expostas através de SELECT * consultas. Sua API pode começar a vazar hashes de senhas, SSNs ou dados internos de negócios que nunca foram destinados para aquele endpoint.

Manutenibilidade do código: Quando SELECT * consultas quebram após alterações de esquema, a falha ocorre em tempo de execução, não em tempo de compilação. Uma nova coluna não nula ou um campo renomeado causa erros de produção. Listas explícitas de colunas deixam as dependências claras e quebram as builds quando os esquemas mudam de forma incompatível.

Exemplos de código

❌ Não-conforme:

async function getUserProfile(userId) {
    const query = 'SELECT * FROM users WHERE id = ?';
    const [user] = await db.execute(query, [userId]);

    return {
        name: user.name,
        email: user.email,
        createdAt: user.created_at
    };
}

Por que está errado: Isso recupera todas as colunas, incluindo campos potencialmente sensíveis como password_hash, ssn, internal_notes ou deleted_at. À medida que o schema cresce, esta query se torna mais lenta e expõe mais dados, embora a aplicação utilize apenas três campos.

✅ Compatível:

async function getUserProfile(userId) {
    const query = `
        SELECT name, email, created_at
        FROM users
        WHERE id = ?
    `;
    const [user] = await db.execute(query, [userId]);

    return {
        name: user.name,
        email: user.email,
        createdAt: user.created_at
    };
}

Conclusão

Sempre especifique listas explícitas de colunas em consultas SQL. Isso evita vazamentos de dados, melhora o desempenho e torna claras as dependências entre código e esquema. O pequeno custo inicial de digitar os nomes das colunas evita classes inteiras de problemas de segurança e desempenho.