Depurador de Queries de Base de Datos

El Problema

Los bugs de base de datos se esconden detras de capas de abstraccion. Tu ORM genera una query que se ve bien pero toma 30 segundos. Una carga de pagina dispara 200 queries separadas en vez de una (el problema N+1). Los connection pools se agotan bajo carga. Los deadlocks aparecen aleatoriamente cuando dos transacciones pelean por las mismas filas. El codigo de la aplicacion se ve correcto — el problema vive en el SQL generado, indices faltantes o niveles de aislamiento de transacciones.

El Prompt

Eres un especialista en depuracion de bases de datos. Diagnostica este problema de performance o correctitud:

BASE DE DATOS: [PostgreSQL/MySQL/MongoDB/SQLite + version]
ORM/DRIVER: [ej. Prisma, Sequelize, TypeORM, Drizzle, SQL raw]
SINTOMA: [ej. "pagina carga en 8 segundos", "registros duplicados", "timeouts de conexion intermitentes"]

QUERY O CODIGO ORM:
[pega la query, llamada ORM o SQL generado]

PLAN DE EXPLAIN (si disponible):
[pega salida de EXPLAIN ANALYZE]

Realiza diagnostico de base de datos:
1. **Analisis de Query**: Reescribe la query en lenguaje sencillo. Que le esta pidiendo realmente a la base de datos? Es lo que pretendes?
2. **Deteccion N+1**: Esta query se ejecuta dentro de un loop? Cuenta el total de queries por carga de pagina.
3. **Diagnostico de Indices**: Basado en WHERE, JOIN y ORDER BY — que indices deberian existir?
4. **Lectura del Plan de Ejecucion**: Interpreta la salida de EXPLAIN — identifica sequential scans, falta de uso de indices y operaciones de sort costosas.
5. **Salud del Connection Pool**: Verifica tamano del pool, idle timeout y max connections contra el volumen de requests concurrentes.
6. **La Query Optimizada**: Proporciona la query reescrita que resuelve el problema de performance.

Ejemplo de Salida

Analisis: ORM genera SELECT * (47 columnas) cuando solo se necesitan 3 — transfiere 15x mas datos de lo necesario
N+1 detectado: Componente UserList dispara 1 query para usuarios + 1 query por usuario para su avatar — 201 queries para 200 usuarios
Indice faltante: WHERE email = $1 dispara sequential scan en tabla de 2M filas — agregar indice reduce query de 2100ms a 3ms
Connection pool: Max es 5 (default) pero la app maneja 50 requests concurrentes — requests hacen cola
Fix: Usar .select('id', 'name', 'email') + .include('avatar') para eager loading. Agregar indice. Pool max a 20.

Cuando Usar

Usa este skill cuando las paginas cargan lento a pesar de codigo de aplicacion rapido, cuando la CPU o I/O de la base de datos es alta, cuando observas registros duplicados o faltantes, o cuando ves errores de timeout de conexion bajo carga.

Tips Pro

• Siempre EXPLAIN ANALYZE, no solo EXPLAIN — EXPLAIN muestra el plan, pero EXPLAIN ANALYZE ejecuta la query y muestra tiempos reales.
• Loggea todas las queries en desarrollo — habilita SQL logging en tu ORM para ver exactamente que SQL se genera y cuantas queries dispara cada carga de pagina.
• La regla de las 10 queries — si una sola carga de pagina ejecuta mas de 10 queries, casi seguro tienes un problema N+1.
• Los indices no son gratis — cada indice acelera lecturas pero ralentiza escrituras. Para tablas con muchas escrituras, perfila ambas antes de agregar indices.