Consultas lentas y reporte nocturno que no termina
Una base de datos de pedidos crece 8% mensual y ya tiene 40 millones de filas en la tabla principal. Dos síntomas: (1) el reporte nocturno de ventas por sucursal, que antes tardaba 15 minutos, ahora tarda 6 horas y a veces no termina antes de que abra la operación; (2) una pantalla de consulta de pedidos recientes se volvió lenta para todos los usuarios. La tabla tiene índices en la llave primaria y en la fecha del pedido. El reporte filtra por sucursal y rango de fechas y agrupa por día. La pantalla consulta los últimos 7 días de un solo cliente. El equipo propone 'comprar más disco' y 'reiniciar el servidor cada noche'.
1. Diagnostica la causa más probable de cada síntoma y evalúa las propuestas del equipo.
Read the worked answer
Los dos síntomas tienen causas distintas y ambas apuntan a diseño de acceso a datos, no a hardware:
- Reporte nocturno: filtra por sucursal y rango de fechas y agrupa por día. El único índice útil es la fecha; no hay índice por sucursal. Con 40 millones de filas, el motor recorre muchos registros y agrupa en memoria o en disco. El crecimiento del 8% mensual explica la degradación progresiva de 15 min a 6 h: el volumen se duplicó varias veces desde que era aceptable.
- Pantalla de pedidos recientes: consulta los últimos 7 días de un cliente. Si no hay índice que combine cliente y fecha, cada consulta recorre la tabla o usa solo el índice de fecha y descarta casi todo.
Propuestas del equipo:
- 'Comprar más disco': no atiende la causa; si el problema es lectura excesiva, más disco no reduce el trabajo. Solo ayudaría si hubiera falta de espacio, que no se reporta.
- 'Reiniciar cada noche': enmascara el síntoma (limpia caché y conexiones) y no corrige el acceso a datos; además introduce una ventana de indisponibilidad.
La evidencia (crecimiento sostenido y filtros no indexados) apunta a índices y a la forma de la consulta, no a capacidad de almacenamiento.
2. Propón las acciones concretas para que el reporte vuelva a terminar antes de la apertura, considerando que el volumen sigue creciendo 8% mensual.
Read the worked answer
Acciones ordenadas por impacto y riesgo:
- Índice compuesto (sucursal, fecha) para el reporte, y (cliente, fecha) para la pantalla. Atacan directamente los filtros usados. Verificar con el plan de ejecución que el motor los use.
- Revisar la consulta del reporte: evitar funciones sobre columnas indexadas, seleccionar solo las columnas necesarias y agregar por día en la base en lugar de traer filas y agrupar en la aplicación.
- Precalcular agregados: como el reporte es histórico y por día, una tabla resumen diaria por sucursal (actualizada incrementalmente) reduce el costo a una lectura pequeña. Es la única opción que escala frente al 8% mensual.
- Ventana de ejecución: programar el reporte fuera de la ventana de apertura y con alerta si excede un umbral, para detectar la regresión antes de que afecte la operación.
Medir antes y después (tiempo y plan de ejecución) para demostrar la mejora. Con 8% mensual, cualquier solución que dependa del volumen actual volverá a fallar; por eso el precálculo es la pieza estructural, y los índices son el alivio inmediato.