Generación de queries SQL
Describe en palabras simples, la IA escribe el SQL
Los agujeros de escribir SQL
JOIN incorrecto, subconsultas anidadas que marean
3 tablas con JOIN, result tiene 10 veces más filas de lo esperado — ¿cuál JOIN falló? Paso media hora hasta descubrir que la relación es many-to-many y no la traté.
Subconsulta anidada 3 niveles, termino sin entender qué hace. Un colega pregunta "¿qué saca este SQL?" y paso dos minutos pensando.
Peor: query tarda 30 segundos. EXPLAIN no muestra nada claro. Agrego índice y se pone más lento. ¿Qué falla?
OpenClaw: entiende la lógica, escribe SQL confiable
Tú en lenguaje simple: "dame total gastado cada usuario últimos 30 días, de mayor a menor". OpenClaw: SQL normalizedo listo.
No es traducción simple: entiende relaciones entre tablas, volumen de datos, índices. SQL correcto y rápido.
¿Query lenta? Pasa SQL + EXPLAIN, OpenClaw te dice dónde es el cuello, qué índice agregar, cómo reescribir más rápido.Es como tener un DBA al lado.
3 prompts SQL, cubre 90% de lo cotidiano
Desde query diaria hasta optimización, úsalos cuando necesites.
Datos diarios: usuarios nuevos últimos 30 días por canal
La instrucción de oro
Tengo estas tablas:
- users (id, name, email, channel, created_at, status)
- user_profiles (user_id, age, gender, city)
Escribí SQL que:
1. Nuevos usuarios cada día últimos 30 días
2. Agrupados por canal de registro (channel)
3. También calcule tasa de retención al día siguiente para cada canal
4. Ordena descendiente por fecha
DB: MySQL 8.0, tabla users ~5M filas.
Dame también los índices sugeridos.Query diaria más común. Dile al modelo qué BD usas (MySQL, PostgreSQL, etc.) y tamaño de datos, sintaxis varía y el volumen afecta la estrategia.
Optimización de query lenta: SQL de 30 segundos, salva
Técnica avanzada
Este SQL tarda 30 segundos, optimiza:
[pega tu SQL lento]
EXPLAIN:
[pega resultado EXPLAIN]
Analiza:
1. ¿Dónde es el cuello? (full scan? tabla temporal? file sort?)
2. Índices que necesito (dame CREATE INDEX)
3. Cómo reescribir el SQL igual pero más rápido
4. Estima tiempo después de optimizar
DB: PostgreSQL 15, ~20M filas.Para optimizar, SIEMPRE carga EXPLAIN. De lo contrario, es adivinanza. También dile el volumen — estrategia para 100 filas vs 20M es completamente distinta.
Query complejo: análisis de gasto de usuarios
La instrucción de oro
3 tablas:
- users (id, name, registered_at)
- orders (id, user_id, product_id, amount, created_at, status)
- products (id, name, category, brand)
Query que:
1. Total gastado cada usuario (solo órdenes completadas)
2. Categoría donde cada usuario compró más (si hay empate, la primera)
3. Primera y última compra de cada usuario
4. Solo usuarios con gasto en últimos 12 meses
5. Top 100 ordenado por gasto descendente
DB: MySQL 8.0. Usa CTE para mejor legibilidad.Multi-tabla + agregación + ranking, error fácil si lo escribes. CTE de la IA lo hace legible y después cambios no rompen todo.
Configuración de conexión a base de datos
Configuración para que OpenClaw conecte directo (opcional, sin esto también genera SQL).
Configuración de DB (.openclaw.yml)
# Conexión a BD (opcional, si configuras OpenClaw consulta para verificar resultados)
database:
type: mysql # mysql / postgresql / sqlite
host: localhost
port: 3306
database: my_app
user: readonly_user # ¡¡Muy recomendado cuenta de solo lectura!!
password_env: DB_PASSWORD # Lee contraseña de env, no hardcodeado
# Límites de seguridad
read_only: true # Solo SELECT, no cambies datos
max_rows: 10000 # Máx filas por query
timeout: 30 # Timeout query (segundos)
# Sin BD configurada también generará SQL, solo que no verifica resultados
# Si describes bien las tablas, igual sale bien
Conexión a producción: SIEMPRE cuenta read-only. OpenClaw tiene protecciones pero una capa más de seguridad nunca sobra. Si es posible, conecta a réplica read-only, no a master.
Escritura SQL: OpenClaw vs ChatGPT
Ambos generan SQL pero hay diferencias.
OpenClaw
- Lee schema de tu BD, SQL coincide 100% con tus tablas reales
- Conecta a BD y verifica el query (con cuenta read-only)
- Contexto: recuerda queries anteriores, no repites preguntas
- Seguro: schema y lógica no van a terceros
VS
ChatGPT
- Genera según tu descripción de tablas, mucha adivinanza
- No verifica, no sabes si sintaxis es correcta hasta probar
- Contexto limitado, chats largos olvida información
- A veces sintaxis correcta pero lógica equivocada, difícil de debuggear
Caso real
Analista de datos: jefe pide urgente
3 PM, jefe te escribe: "dame ROI últimas 3 meses por canal, semanal, antes de las 5". No dominas bien esas tablas, escribir SQL es riesgo.
Solución OpenClaw
Pasas el schema a OpenClaw, en palabras simples pides el report, 2 minutos tenes SQL. Conectas, verificas resultado, le pides explicación de cada línea — aprendes también. 4 PM entregas, adelantado.
Hacerlo a mano
Busca documentación de tablas, escribe SQL, JOIN falla, resultado no cuadra. Media hora de debug. Función de fecha mal usada. No logras a las 5, le pides al jefe "media hora más".
Trucos SQL
Cuando pidas SQL, siempre dile al modelo: tipo de BD, volumen aproximado de datos, índices que ya tienes. Estas 3 cosas afectan mucho la calidad del SQL generado.
Queries complejos: pídele CTE en lugar de subconsultas anidadas. CTE es mucho más legible, cambios después son sencillos.
Hábito: siempre que la IA genera SQL, corre con LIMIT 100 primero para verificar resultado. Después sí en tabla completa. Si hay JOINs múltiples, cuidado con producto cartesiano — un error y la BD se cuelga.