(Sí, estoy agregando otro responder. Justificación:aborda el problema subyacente de una manera diferente).
El problema subyacente parece ser que hay una tabla de "transacciones" en constante crecimiento de la que se derivan varias estadísticas, como SUM(amount) . El rendimiento de esto solo empeorará cada vez más a medida que crezcan las tablas.
La base para esta Respuesta será mirar los datos de dos maneras:"Historial" y "Actual". Transactions es la Historia. Una nueva tabla sería la Current totales para cada Usuario. Pero veo varias formas de hacerlo. Cada uno involucra algún tipo de subtotal(es) para evitar agregar 773K filas para obtener la respuesta.
- La forma bancaria tradicional... Cada noche cuenta las
Transactionsdel día y agréguelos aCurrent. - La forma de vista materializada... Cada vez que se agrega una fila a
Transactions, incrementaCurrent. - Híbrido:mantenga los subtotales diarios en una "tabla de resumen". Sume esos subtotales para obtener el
SUMhasta anoche.
Más discusión en mi blog sobre Tablas de resumen .
Tenga en cuenta que el saldo actualizado al segundo para la forma bancaria o híbrida es un poco complicado:
- Obtener la cantidad de anoche
- Agregue cualquier Transacción que haya ocurrido durante el día.
Cualquiera de los enfoques será mucho más rápido que escanear todas las filas de 773K para el usuario, pero será un código más complejo.
