Prompt para escribir una consulta SQL

Por qué el SQL generado por IA suele romperse en la primera ejecución

Una IA puede escribir SQL sintácticamente perfecto y aun así entregarte una consulta que falle o, peor, que devuelva números silenciosamente erróneos. La razón casi siempre es el contexto, no la competencia. Cuando pides una consulta sin describir tus tablas, el modelo inventa un esquema plausible: supone que tu tabla de usuarios tiene un id y un created_at, que los pedidos enlazan de vuelta con user_id, y que existe una columna de estado. A veces acierta. A menudo la columna es en realidad customer_id, o la fecha está guardada como texto, o no hay columna de estado en absoluto. El prompt de arriba arregla esto desde el origen al exigirte que pegues tu esquema real o tus sentencias CREATE TABLE. Una vez que el modelo puede ver los nombres y tipos de columna reales, deja de adivinar y empieza a corresponder la consulta con tu base de datos.

El dialecto no es un detalle

SQL es una familia de lenguajes, no un solo lenguaje. Una consulta que funciona en PostgreSQL puede fallar en MySQL porque las funciones difieren. La concatenación de cadenas usa || en Postgres pero CONCAT() en MySQL. La aritmética de fechas, LIMIT frente a TOP, el soporte de funciones de ventana, e ILIKE para coincidencias sin distinguir mayúsculas, todo varía según el motor. Por eso el prompt te pide que indiques el dialecto desde el principio. Decirle al modelo "esto es BigQuery" o "esto es SQL Server" cambia a qué funciones recurre y evita el frustrante bucle de pegar un error, recibir un arreglo y toparte con el siguiente problema específico del dialecto. Si no estás seguro de tu motor, merece la pena comprobarlo antes de generar nada, porque da forma a cada elección de función en el resultado.

Los JOINs explícitos y el manejo de NULL separan lo correcto de lo plausible

La instrucción de usar JOINs explícitos con alias claros va de corrección y legibilidad a la vez. Los joins de estilo coma con una cláusula WHERE gigante esconden la lógica del join y facilitan producir sin querer un producto cartesiano. Las palabras clave explícitas INNER JOIN y LEFT JOIN obligan a enunciar la relación con claridad, y elegir entre ellas importa: un inner join descarta silenciosamente las filas que no tienen coincidencia, así que un informe de "clientes y sus pedidos" escrito con el tipo de join equivocado excluirá silenciosamente a los clientes que nunca pidieron. El requisito de manejar los NULL de forma segura caza la otra trampa clásica: las comparaciones y agregaciones se comportan de forma inesperada alrededor de NULL. Un filtro como WHERE status != 'closed' excluirá las filas donde status es NULL, lo que rara vez es lo que pretendes. Nombrar estas preocupaciones en el prompt hace que el modelo razone sobre ellas en lugar de irse por el camino feliz por defecto.

La nota de suposiciones es tu red de seguridad

El requisito final —una explicación de una línea más cualquier suposición— es lo que convierte una respuesta de caja negra en algo en lo que puedes confiar. Cuando el modelo escribe "asumiendo que cada pedido pertenece a exactamente un cliente y que los reembolsos están excluidos", puedes confirmar o corregir esa lógica de inmediato antes de ejecutar nada. La ambigüedad es de donde vienen los informes erróneos, y sacarla a la luz en lenguaje sencillo es mucho más barato que depurar una consulta que se ejecutó con éxito pero contó lo que no era. Lee siempre esa nota, y prueba siempre la consulta con una muestra pequeña antes de apuntarla a datos de producción.

Por qué funciona este prompt

El SQL de la IA falla cuando adivina tu esquema o dialecto. Este prompt aporta ambos más el objetivo exacto, para que la consulta se corresponda con tus tablas reales y funcione en tu motor, y la nota de suposiciones caza las ambigüedades antes de que causen resultados erróneos.

Cómo personalizarlo

• Pega tu esquema real para que los nombres de columna sean correctos.
• Indica el dialecto; las funciones difieren entre bases de datos.
• Prueba con una muestra antes de ejecutar en datos de producción.

Variantes del prompt para probar

Optimizar una consulta lenta existente

Eres un ingeniero de rendimiento de bases de datos sénior. Aquí tienes una consulta SQL lenta en [base de datos: PostgreSQL/MySQL/etc]:
[pega la consulta]
Esquema y recuentos aproximados de filas:
[pega tablas, columnas, índices y recuentos de filas]
Reescríbela para que se ejecute más rápido. Explica qué era lento (p. ej. índice ausente, función sobre una columna indexada, subconsulta innecesaria), sugiere cualquier índice a añadir, y confirma que la reescritura devuelve resultados idénticos. Mantén el dialecto correcto.

Explicar qué hace una consulta

Eres un tutor de SQL. Explica esta consulta de [dialecto de base de datos] en lenguaje sencillo, paso a paso:
[pega la consulta]
Describe qué hace cada JOIN, filtro y agregación, cómo se ve el conjunto de resultados, y señala cualquier caso límite o error que notes (como el manejo de NULL o un join que podría descartar filas). Asume que estoy cómodo con SQL básico pero no con esta consulta.

Convertir una consulta entre dialectos

Convierte esta consulta SQL de [dialecto origen] a [dialecto destino]:
[pega la consulta]
Sustituye cualquier función específica del dialecto, manejo de fechas, operaciones de cadenas y sintaxis (como LIMIT frente a TOP) por los equivalentes correctos. Enumera cada cambio que hiciste y por qué, y marca cualquier cosa que no tenga equivalente directo y necesite una solución alternativa.

Errores comunes que debes evitar

• No pegar el esquema real. Sin tus nombres reales de tabla y columna, la IA los inventa y la consulta falla o referencia columnas que no existen. Pega siempre las sentencias CREATE TABLE o una lista de columnas.
• Saltarse el dialecto. Las funciones difieren entre motores, así que una consulta para una base de datos puede dar error en otra. Indica MySQL, PostgreSQL, SQL Server, o lo que de verdad uses.
• Usar un INNER JOIN cuando querías conservar las filas sin coincidencia. Un inner join descarta silenciosamente los registros sin coincidencia; usa un LEFT JOIN y COALESCE cuando necesites cada fila de la tabla principal.
• Ignorar los NULL en los filtros. Una condición como status != 'closed' excluye las filas donde status es NULL. Decide explícitamente con IS NULL / IS NOT NULL o COALESCE.
• Confiar en la consulta sin probarla. Incluso el SQL de aspecto correcto puede contar lo que no era. Lee la nota de suposiciones, y luego ejecútala con una muestra pequeña antes de tocar los datos de producción.

Preguntas frecuentes

¿De verdad necesito pegar todo mi esquema?

¿Por qué la misma consulta falla en MySQL pero funciona en PostgreSQL?

¿Es seguro ejecutar SQL generado por IA en producción?

¿Puede la IA ayudarme a acelerar una consulta lenta?

Consejo: sustituye las partes entre [corchetes] por tus propios datos antes de enviar. Cuanto más concreto seas — público, tono, objetivo, restricciones — mejor será el resultado de la IA.