Módulo 11 de 12 · Índices

🐌 Identificar Consultas Lentas

Diagnóstico de rendimiento: pg_stat_statements, slow log, análisis

💡 Piénsalo así: Identificar consultas lentas es como ser un detective de rendimiento. Tienes herramientas: pg_stat_statements (la cámara de seguridad que graba TODAS las consultas), slow query log (el libro de incidencias donde se reportan las que tardan), y EXPLAIN (la lupa para analizar cada caso).

🎯 ¿Qué aprenderás?

🔎 Diagnóstico Interactivo

Haz clic en cada consulta para ver el diagnóstico:

1️�£ SELECT * FROM pedidos WHERE fecha > "2024-01-01"3.2s � ï¸

Que aprenderas?

✓ Identificar consultas lentas usando pg_stat_statements y slow query log.
✓ Usar EXPLAIN ANALYZE para diagnosticar el origen de la lentitud.
✓ Detectar full table scans inesperados y indices faltantes.
✓ Aplicar correcciones: crear indices, reescribir consultas, ajustar configuracion.
🔍 Problema: Seq Scan en pedidos (1M filas). Solución: CREATE INDEX idx_pedidos_fecha ON pedidos (fecha). Resultado: 0.02s �’ 160x más rápido.
2️�£ SELECT DISTINCT ciudad FROM clientes WHERE pais = "España"1.1s �¡
🔍 Problema: Índice en (pais) no ayuda con DISTINCT en ciudad. Solución: CREATE INDEX ON clientes (pais, ciudad) o usa Skip Scan (PG 18+). Resultado: 0.05s �’ 22x más rápido.
3️�£ SELECT * FROM productos ORDER BY precio DESC LIMIT 104.5s � ï¸
🔍 Problema: Sort en memoria (200k filas). Solución: CREATE INDEX idx_precio ON productos (precio DESC). Resultado: 0.001s �’ ¡4500x más rápido! Index Scan evita ordenar.
4️�£ SELECT COUNT(*) FROM usuarios WHERE activo = true0.3s �…
🔍 Análisis: Si hay un índice parcial WHERE activo=true, COUNT(*) es instantáneo. Sin índice: Seq Scan. Opción: CREATE INDEX idx_activo ON usuarios (activo) WHERE activo = true. Resultado: 0.01s.
💬 Explora cada consulta para aprender a diagnosticar lentitud

🏅 Performance Detective 🏅

¡Diagnóstico de consultas lentas dominado!

📌 Resumen del módulo