Se o comando INSERT coloca os dados para dentro do banco, o SELECT é o responsável por extrair inteligência, gerar relatórios e alimentar as telas das nossas aplicações. Ele é, sem dúvidas, o comando mais utilizado no dia a dia de qualquer profissional de Dados ou DevOps.

A sintaxe básica do SELECT parece muito simples e natural — afinal, ela se lê quase como uma frase em inglês. Porém, existe uma pegadinha: o banco de dados não lê o comando na mesma ordem em que você o escreve.

Neste post, vamos entender a fundo como o SELECT funciona, como filtrar dados de forma eficiente no PostgreSQL e como o motor do banco processa sua consulta nos bastidores.

A Sintaxe Básica: O que você escreve

Para extrair dados, você precisa dizer ao banco quais colunas você quer (SELECT) e de qual tabela elas devem vir (FROM).

SELECT coluna1, coluna2 FROM nome_da_tabela;

Se você quiser trazer todas as colunas de uma tabela, utiliza-se o asterisco (*):

SELECT * FROM servidores;

(Spoilers: usar o asterisco em produção é um perigo, e logo vamos entender o porquê).

Como o Banco de Dados Realmente Funciona (A Ordem de Execução)

Para entender filtros e consultas avançadas, você precisa virar uma chave na sua cabeça. Quando você envia uma query para o PostgreSQL, ele a executa em uma ordem lógica diferente da escrita.

Olhe para uma query completa com filtro:

SELECT nome, ip_publico 
FROM servidores 
WHERE status = 'ativo';

Para o olho humano, lemos de cima para baixo: SELECT -> FROM -> WHERE. Mas o motor do Postgres executa assim:

1. FROM servidores: Primeiro, o banco precisa saber em qual arquivo ou tabela os dados estão guardados. Ele vai até a tabela servidores.
2. WHERE status = 'ativo': Com a tabela aberta, ele linha por linha (ou usando índices) descartando tudo o que não for ativo. Ele filtra o volume de dados primeiro.
3. SELECT nome, ip_publico: Só agora, com os dados filtrados, o banco recorta apenas as colunas que você pediu e entrega o resultado na tela.

Entender essa ordem (FROM -> WHERE -> SELECT) evita que você tente filtrar no WHERE usando um apelido (alias) que você acabou de criar no SELECT, algo que gera muitos erros em iniciantes.

Filtrando Dados como um Profissional (O Poder do WHERE)

O segredo de um bom SELECT está na precisão do seu filtro. Vamos ver os operadores mais comuns no dia a dia de infraestrutura e dados usando o PostgreSQL:

1. Operadores de Comparação (=, >, <, !=)

Perfeito para buscar estados exatos ou métricas de recursos.

SELECT nome, vcpus FROM servidores 
WHERE vcpus >= 8;

2. Operadores Lógicos (AND, OR, NOT)

Permitem combinar múltiplos filtros para refinar a busca.

SELECT nome, ambiente FROM deploys 
WHERE ambiente = 'prod' AND status != 'sucesso';

3. Buscando por texto parcial (LIKE e ILIKE)

Muito útil para buscar logs, tags de instâncias ou nomes de aplicações. O % funciona como um curinga (representa qualquer texto).

• No Postgres, o LIKE diferencia maiúsculas de minúsculas.
• O ILIKE é exclusivo do PostgreSQL e ignora essa diferença (case-insensitive):

-- Vai encontrar 'api-prod', 'prod-api', 'PROD-backend', etc.
SELECT nome_app FROM deploys 
WHERE nome_app ILIKE '%prod%';

4. Limitando e Ordenando Resultados (ORDER BY e LIMIT)

Em DevOps, muitas vezes você quer apenas o último registro de log ou o servidor que está consumindo mais recursos.

SELECT nome, memoria_gb FROM servidores 
ORDER BY memoria_gb DESC 
LIMIT 5;

Aqui, ordenamos de forma decrescente (DESC) pela memória e limitamos o resultado para trazer apenas o “Top 5”.

Boas Práticas em Ambientes de Produção

1. Abandone o SELECT * em suas Aplicações

Usar SELECT * é prático quando estamos explorando o banco no terminal (CLI) ou no DBeaver. Porém, dentro do código da sua aplicação ou em um pipeline, nunca faça isso.

Se sua tabela tiver 50 colunas e você só precisa do nome e do id, trazer as outras 48 colunas vai desperdiçar banda de rede, memória do servidor e processamento do Postgres. Além disso, se alguém alterar a estrutura da tabela, sua aplicação pode quebrar por receber dados inesperados.

2. Cuidado com filtros que não usam Índices

Se você rodar um SELECT com WHERE em uma tabela de logs com 100 milhões de linhas procurando por uma coluna que não está indexada, o Postgres será obrigado a fazer um Sequential Scan (ler o disco inteiro, linha por linha). Isso pode travar o banco e derrubar sua aplicação.

Conclusão

O SELECT básico é a ferramenta com a qual você vai passar 80% do seu tempo interagindo. Dominar a ordem em que o banco processa a query e saber filtrar os dados de forma cirúrgica é o passo fundamental antes de começarmos a agrupar ou somar valores.

No próximo post, vamos subir o nível dessa discussão e entender como o SQL faz cálculos e agrupamentos complexos usando as cláusulas GROUP BY, HAVING e funções de agregação como COUNT e SUM.

Ficou clara a ordem em que o Postgres lê a sua query? Se tiver alguma dúvida sobre como estruturar seus filtros, deixa aqui nos comentários!