(Sì, ne sto aggiungendo un altro Rispondere. Motivazione:affronta il problema di fondo in modo diverso.)
Il problema di fondo sembra essere che esiste una tabella di "transazioni" in continua crescita da cui derivano varie statistiche, come SUM(amount) . Le prestazioni di questo non potranno che peggiorare man mano che i tavoli crescono.
La base per questa risposta sarà guardare i dati in due modi:"Cronologia" e "Attuale". Transactions è la Storia. Una nuova tabella sarebbe la Current totali per ogni Utente. Ma vedo diversi modi per farlo. Ciascuno comporta una qualche forma di subtotale/i in modo da evitare di aggiungere 773.000 righe per ottenere la risposta.
- Il metodo bancario tradizionale... Ogni notte calcola le
Transactionsdel giorno e aggiungili aCurrent. - Il modo di visualizzazione materializzata... Ogni volta che viene aggiunta una riga a
Transactions, incrementaCurrent. - Ibrido:conserva i totali parziali giornalieri in una "tabella riepilogativa". Somma quei subtotali per ottenere il
SUMfino a ieri sera.
Altre discussioni nel mio blog su Tabelle di riepilogo .
Tieni presente che il saldo fino al secondo per la modalità bancaria o ibrida è un po' complicato:
- Ricevi l'importo della scorsa notte
- Aggiungi tutte le Transazioni avvenute durante il giorno.
Qualsiasi approccio sarà molto più veloce della scansione di tutte le 773.000 righe per l'utente, ma sarà un codice più complesso.
