Início › Biblioteca de prompts › Prompt para escrever uma consulta SQL

Prompt para escrever uma consulta SQL

Q: Eu realmente preciso colar todo o meu esquema?

Você precisa do suficiente para que o modelo referencie colunas reais: as tabelas relevantes, suas colunas-chave e como elas se relacionam. Você não precisa colar cada tabela do banco, apenas aquelas que a consulta toca mais qualquer chave de junção. Os nomes precisos das colunas são o que evita que a consulta quebre na primeira execução.

Q: Por que a mesma consulta falha no MySQL, mas funciona no PostgreSQL?

Porque são dialetos SQL diferentes. As funções para strings, datas e paginação diferem, e funções como algumas de janela ou ILIKE não estão disponíveis em todo lugar. Sempre diga à IA qual motor você usa para que ela escolha as funções certas em vez de adivinhar.

Q: É seguro executar SQL gerado por IA em produção?

Não sem verificá-lo primeiro. Leia a explicação e as suposições, depois teste em uma amostra ou em uma réplica de leitura. Tenha cuidado especial com qualquer consulta que grava ou apaga dados: examine de perto a cláusula WHERE e considere envolver as mudanças em uma transação para poder desfazê-las se o resultado estiver errado.

Q: A IA pode me ajudar a acelerar uma consulta lenta?

Sim, se você der a ela o que precisa: a consulta, o esquema, os índices existentes e contagens aproximadas de linhas. Ela pode detectar índices ausentes, funções aplicadas a colunas indexadas e subconsultas desnecessárias, e depois sugerir uma reescrita. Confirme que a reescrita retorna resultados idênticos antes de adotá-la.

Descreva seus dados em linguagem simples e obtenha uma consulta SQL correta e eficiente para o seu banco de dados.

Código · Funciona muito bem com Qualquer IA

Prompt pronto para copiar

Você é um engenheiro de dados sênior. Escreva uma consulta SQL para [banco de dados: MySQL/PostgreSQL/etc].
Objetivo: [o que a consulta deve retornar].
Esquema:
[lista de tabelas e colunas, ou cole as instruções CREATE TABLE]
Requisitos:
- Sintaxe correta para o dialeto indicado.
- Use JOINs explícitos e aliases claros.
- Trate NULLs e casos-limite de forma segura.
- Evite SELECT *; enumere as colunas necessárias.
- Acrescente uma explicação de uma linha e anote qualquer suposição.

Quer uma versão sob medida?

Responda a algumas perguntas rápidas e o Gerador de consultas SQL criará um prompt personalizado com seus dados exatos.

🗄️ Abrir o Gerador de consultas SQL

Por que o SQL gerado por IA costuma quebrar na primeira execução

Uma IA pode escrever um SQL sintaticamente perfeito e ainda assim entregar uma consulta que falha ou, pior, que retorna números silenciosamente errados. A razão é quase sempre o contexto, não a competência. Quando você pede uma consulta sem descrever suas tabelas, o modelo inventa um esquema plausível: ele supõe que sua tabela de usuários tem um id e um created_at, que os pedidos se ligam por user_id e que existe uma coluna de status. Às vezes ele acerta. Muitas vezes a coluna na verdade é customer_id, ou a data está armazenada como texto, ou não há coluna de status nenhuma. O prompt acima resolve isso na origem ao obrigar você a colar seu esquema real ou suas instruções CREATE TABLE. Assim que o modelo consegue ver os nomes e tipos reais das colunas, ele para de adivinhar e começa a fazer a consulta corresponder ao seu banco de dados.

O dialeto não é um detalhe

SQL é uma família de linguagens, não uma única linguagem. Uma consulta que funciona no PostgreSQL pode falhar no MySQL porque as funções diferem. A concatenação de strings usa || no Postgres, mas CONCAT() no MySQL. A aritmética de datas, LIMIT versus TOP, o suporte a funções de janela e ILIKE para correspondências sem distinção de maiúsculas, tudo varia conforme o motor. É por isso que o prompt pede que você indique o dialeto logo de início. Dizer ao modelo "isto é BigQuery" ou "isto é SQL Server" muda as funções às quais ele recorre e evita o frustrante ciclo de colar um erro, receber uma correção e cair no próximo problema específico do dialeto. Se você não tem certeza do seu motor, vale a pena verificar antes de gerar qualquer coisa, porque isso molda cada escolha de função no resultado.

JOINs explícitos e tratamento de NULL separam o correto do plausível

A instrução de usar JOINs explícitos com aliases claros visa tanto a correção quanto a legibilidade. As junções no estilo vírgula com uma cláusula WHERE gigantesca escondem a lógica de junção e facilitam a produção involuntária de um produto cartesiano. As palavras-chave explícitas INNER JOIN e LEFT JOIN forçam você a enunciar a relação com clareza, e escolher entre elas importa: um inner join descarta silenciosamente as linhas sem correspondência, então um relatório de "clientes e seus pedidos" escrito com o tipo errado de junção excluirá silenciosamente os clientes que nunca fizeram pedidos. O requisito de tratar NULLs de forma segura captura a outra armadilha clássica: comparações e agregações se comportam de forma inesperada em torno de NULL. Um filtro como WHERE status != 'closed' excluirá as linhas em que status é NULL, o que raramente é o que você quer. Nomear essas preocupações no prompt faz o modelo raciocinar sobre elas em vez de tomar o caminho fácil por padrão.

A nota de suposições é a sua rede de segurança

O requisito final — uma explicação de uma linha mais qualquer suposição — é o que transforma uma resposta de caixa-preta em algo em que você pode confiar. Quando o modelo escreve "supondo que cada pedido pertence a exatamente um cliente e que os reembolsos estão excluídos", você pode confirmar ou corrigir essa lógica imediatamente antes de executar qualquer coisa. A ambiguidade é de onde vêm os relatórios errados, e trazê-la à tona em linguagem simples é muito mais barato do que depurar uma consulta que rodou com sucesso, mas contou a coisa errada. Sempre leia essa nota e sempre teste a consulta em uma pequena amostra antes de apontá-la para dados de produção.

Por que este prompt funciona

O SQL da IA falha quando ela adivinha seu esquema ou seu dialeto. Este prompt fornece os dois mais o objetivo exato, para que a consulta corresponda às suas tabelas reais e funcione no seu motor, e a nota de suposições captura as ambiguidades antes que causem resultados errados.

Como personalizar

Cole seu esquema real para que os nomes das colunas estejam corretos.
Indique o dialeto; as funções diferem entre bancos de dados.
Teste em uma amostra antes de executar em dados de produção.

Exemplo de resultado

Apenas um exemplo

Objetivo: Receita total por cliente em 2024, incluindo os clientes que não fizeram nenhum pedido (PostgreSQL).

Consulta:

SELECT c.id, c.name, COALESCE(SUM(o.total), 0) AS revenue_2024 FROM customers c LEFT JOIN orders o ON o.customer_id = c.id AND o.order_date >= '2024-01-01' AND o.order_date < '2025-01-01' GROUP BY c.id, c.name ORDER BY revenue_2024 DESC;

Explicação: Soma os totais dos pedidos de 2024 de cada cliente, usando um LEFT JOIN para que os clientes sem pedidos ainda apareçam, e COALESCE para exibi-los como 0 em vez de NULL.

Suposições: O filtro de data fica na condição do JOIN (não no WHERE) para que não transforme o LEFT JOIN em inner join; orders.total já está líquido de impostos; os reembolsos não são armazenados nesta tabela.

Variações de prompt para testar

Otimizar uma consulta lenta existente

Você é um engenheiro sênior de desempenho de bancos de dados. Aqui está uma consulta SQL lenta em [banco de dados: PostgreSQL/MySQL/etc]:
[cole a consulta]
Esquema e contagens aproximadas de linhas:
[cole tabelas, colunas, índices e contagens de linhas]
Reescreva-a para que rode mais rápido. Explique o que estava lento (por exemplo, índice ausente, função sobre uma coluna indexada, subconsulta desnecessária), sugira qualquer índice a acrescentar e confirme que a reescrita retorna resultados idênticos. Mantenha o dialeto correto.

Explicar o que uma consulta faz

Você é um tutor de SQL. Explique esta consulta [dialeto de banco de dados] em linguagem simples, passo a passo:
[cole a consulta]
Descreva o que cada JOIN, filtro e agregação faz, como fica o conjunto de resultados e aponte qualquer caso-limite ou bug que você notar (como o tratamento de NULLs ou uma junção que poderia descartar linhas). Suponha que estou à vontade com SQL básico, mas não com esta consulta.

Converter uma consulta entre dialetos

Converta esta consulta SQL do [dialeto de origem] para o [dialeto de destino]:
[cole a consulta]
Substitua qualquer função específica do dialeto, tratamento de datas, operações de strings e sintaxe (como LIMIT versus TOP) pelos equivalentes corretos. Enumere cada mudança que você fez e por quê, e sinalize tudo o que não tenha equivalente direto e exija uma solução alternativa.

Erros comuns a evitar

Não colar o esquema real. Sem os seus nomes reais de tabela e coluna, a IA os inventa e a consulta falha ou referencia colunas inexistentes. Sempre cole as instruções CREATE TABLE ou uma lista de colunas.
Pular o dialeto. As funções diferem entre motores, então uma consulta para um banco pode dar erro em outro. Indique MySQL, PostgreSQL, SQL Server, ou o que você realmente usa.
Usar um INNER JOIN quando você queria manter as linhas sem correspondência. Um inner join descarta silenciosamente os registros sem correspondência; use um LEFT JOIN e COALESCE quando você precisa de cada linha da tabela principal.
Ignorar os NULLs nos filtros. Uma condição como status != 'closed' exclui as linhas em que status é NULL. Decida explicitamente com IS NULL / IS NOT NULL ou COALESCE.
Confiar na consulta sem testá-la. Mesmo um SQL de aparência correta pode contar a coisa errada. Leia a nota de suposições, depois execute-a em uma pequena amostra antes de tocar nos dados de produção.

Perguntas frequentes

Eu realmente preciso colar todo o meu esquema?

Você precisa do suficiente para que o modelo referencie colunas reais: as tabelas relevantes, suas colunas-chave e como elas se relacionam. Você não precisa colar cada tabela do banco, apenas aquelas que a consulta toca mais qualquer chave de junção. Os nomes precisos das colunas são o que evita que a consulta quebre na primeira execução.

Por que a mesma consulta falha no MySQL, mas funciona no PostgreSQL?

Porque são dialetos SQL diferentes. As funções para strings, datas e paginação diferem, e funções como algumas de janela ou ILIKE não estão disponíveis em todo lugar. Sempre diga à IA qual motor você usa para que ela escolha as funções certas em vez de adivinhar.

É seguro executar SQL gerado por IA em produção?

Não sem verificá-lo primeiro. Leia a explicação e as suposições, depois teste em uma amostra ou em uma réplica de leitura. Tenha cuidado especial com qualquer consulta que grava ou apaga dados: examine de perto a cláusula WHERE e considere envolver as mudanças em uma transação para poder desfazê-las se o resultado estiver errado.

A IA pode me ajudar a acelerar uma consulta lenta?

Sim, se você der a ela o que precisa: a consulta, o esquema, os índices existentes e contagens aproximadas de linhas. Ela pode detectar índices ausentes, funções aplicadas a colunas indexadas e subconsultas desnecessárias, e depois sugerir uma reescrita. Confirme que a reescrita retorna resultados idênticos antes de adotá-la.

Dica: substitua as partes entre [colchetes] pelas suas próprias informações antes de enviar. Quanto mais preciso você for — público, tom, objetivo, restrições — melhor será o resultado da IA.