Cómo monitorizar el rendimiento de las consultas de base de datos: encuentra y corrige las consultas lentas antes de que afecten a tus usuarios

Una página lenta rara vez es una página lenta. La mayoría de las veces es una consulta lenta. Tu aplicación puede estar bien diseñada, tu caché puede estar caliente y tu frontend puede ser rápido — pero un solo índice faltante o una sola consulta sin optimizar puede convertir una petición de 50 milisegundos en un timeout de 5 segundos. A diferencia de un crash duro, una consulta lenta rara vez aparece en el log de errores. Degrada silenciosamente la experiencia hasta que los usuarios se van.

Monitorizar el rendimiento de las consultas de base de datos no es lo mismo que vigilar si tu base de datos está en línea. Ambos importan, pero responden a preguntas distintas. Esta guía repasa las métricas que revelan consultas lentas, el SQL exacto para encontrarlas en PostgreSQL y MySQL, y cómo vigilarlas las 24 horas.

Dos preguntas distintas: ¿está en línea y es rápida?

El monitoring de base de datos se divide en dos capas. El monitoring de disponibilidad responde a una pregunta sencilla: ¿tu aplicación aún puede alcanzar la base de datos y responde en un tiempo razonable? El monitoring del rendimiento de consultas responde a una pregunta más difícil: qué consultas son lentas, por qué lo son y si empeoran a medida que crecen los datos. Necesitas ambos — una base de datos puede ser perfectamente accesible mientras una sola consulta descontrolada pone de rodillas a tu aplicación.

Las métricas que de verdad importan

Antes de salir a cazar consultas lentas, decide qué estás midiendo. Estas cifras separan una base de datos sana de una a punto de causar un incidente:

• Latencia de consultas — cuánto tarda una consulta, expresada como p50, p95 y p99. Un p50 de 10 ms con un p99 de 3 segundos significa que la mayoría de los usuarios van bien, pero algunos esperan.
• Throughput (QPS) — consultas por segundo. Un pico repentino puede revelar una nueva funcionalidad o un vecino ruidoso en infraestructura compartida.
• Tasa de consultas lentas — la proporción de consultas que superan tu umbral (por ejemplo, 500 ms). Es el número que debería alertarte primero.
• Saturación del pool de conexiones — cuando todas las conexiones están ocupadas, las nuevas peticiones esperan. Un tiempo de espera alto suele ser un síntoma de consultas lentas, no falta de conexiones.
• Eventos de lock y deadlock — una sola transacción de larga duración puede bloquear todo lo que hay detrás.

Encuentra consultas lentas en PostgreSQL

PostgreSQL tiene una herramienta que hace la mayor parte del trabajo: la extensión pg_stat_statements. Registra estadísticas agregadas de cada consulta que se ejecuta, incluido el tiempo total, el tiempo medio y el número de llamadas. Actívala una vez y obtendrás una clasificación permanente de tus consultas más lentas.

• Activa la extensión: ejecuta CREATE EXTENSION IF NOT EXISTS pg_stat_statements;, añádela a shared_preload_libraries y reinicia el servidor.
• Ordena tus consultas más lentas por tiempo medio: SELECT query, calls, mean_exec_time, max_exec_time FROM pg_stat_statements ORDER BY mean_exec_time DESC LIMIT 10;
• Acércate a una sola consulta con EXPLAIN ANALYZE. Ejecuta la consulta y muestra el plan, para ver si usa un índice o hace un escaneo completo de tabla.
• Vigila Seq Scan en tablas grandes, una gran diferencia entre filas estimadas y reales, y ordenamientos costosos — las tres causas más comunes de consultas PostgreSQL lentas.

Encuentra consultas lentas en MySQL

MySQL mantiene un log de consultas lentas que puedes activar con unos pocos ajustes. Captura cada consulta que tarda más que long_query_time, lo que lo convierte en la forma más rápida de encontrar a tus peores infractores sin añadir una herramienta de monitoring.

• Actívalo: SET GLOBAL slow_query_log = 1; SET GLOBAL long_query_time = 1; luego localiza el archivo con SHOW VARIABLES LIKE 'slow_query_log_file';
• Inspecciona un plan con EXPLAIN en cualquier SELECT. Mira la columna type — ALL significa escaneo completo de tabla, normalmente lo que hay que corregir.
• Comprueba la cobertura de índices con SHOW INDEX FROM your_table; y busca índices faltantes o sin usar.
• Vigila Threads_running y Threads_connected en SHOW STATUS; un número creciente de threads activos suele significar que las consultas lentas mantienen conexiones abiertas.

Corrige la causa raíz, no el síntoma

Encontrar una consulta lenta es solo la mitad del trabajo. Las correcciones suelen agruparse en unas pocas categorías conocidas:

• Índice faltante — la causa más común. Un índice en tus columnas WHERE y JOIN convierte a menudo un escaneo completo en unos pocos milisegundos.
• El problema N+1 — un ORM que ejecuta una consulta por fila en lugar de una para todo el conjunto. Busca muchas consultas diminutas casi idénticas en tus logs.
• Sobre-fetching — seleccionar columnas que nunca usas o filas que no necesitas. Limita los resultados y selecciona solo lo que muestras.
• Mala configuración del pool de conexiones — un pool demasiado pequeño encola peticiones; uno demasiado grande puede saturar la base de datos. Ajústalo contra el tráfico real.

Sábelo antes que tus usuarios

Las herramientas a nivel de consulta te dicen qué es lento dentro de la base de datos. No te dicen si tu base de datos es accesible desde tu aplicación, ni si una consulta de health-check sigue respondiendo mientras duermes. Ahí es donde entra el monitoring externo.

isthisthing.online te permite crear un Monitor MySQL o PostgreSQL que se conecta a tu base de datos según un calendario, ejecuta un check y mide el Response Time. Si la base de datos deja de responder o un check supera su Timeout, recibes una alerta por Email, Slack u otros canales — antes de que tus usuarios vean un error. Combinado con una línea de tiempo de Incident y una Status Page pública, conviertes «el sitio se puso lento» en un mensaje que envías en lugar de uno que recibes.

Una checklist práctica

• Activa el registro de consultas lentas (PostgreSQL: pg_stat_statements; MySQL: slow_query_log).
• Encuentra tus 10 consultas más lentas y ejecuta EXPLAIN ANALYZE en cada una.
• Corrige primero los índices faltantes y el problema N+1 — dan las mayores ganancias.
• Establece un umbral de latencia y alerta sobre él, no solo sobre errores.
• Añade un Monitor MySQL o PostgreSQL en isthisthing.online para vigilar la disponibilidad y el Response Time desde fuera.
• Revisa las métricas de consultas después de cada despliegue y cada cambio de esquema.

Las consultas lentas no se anuncian. Se acumulan hasta que el sitio se siente lento, la base de datos se satura y estás apagando un incendio que podrías haber evitado. Monitoriza tu base de datos desde dentro y desde fuera, y deja que isthisthing.online te lo diga primero.

Crea tu primer Monitor hoy. Abre tu cuenta gratuita y detecta las consultas lentas antes que tus usuarios.