tabella mysql molto grande e reporting

Inizia esaminando la partition ing la tua tabella se non l'hai già fatto:

Come stai "consolidando" i tuoi dati? Forse il metodo che stai usando non è ottimale. Un buon approccio (fammi sapere se questo è effettivamente ciò che stai facendo) è creare una tabella che contenga dati aggregati. Quindi configuralo in questo modo:

Per prima cosa, mettendo da parte il modo in cui i dati vengono scaricati nella tabella principale...

Crea un lavoro (cron o qualunque cosa tu abbia a portata di mano o già configurato) che venga eseguito a un intervallo specifico, relativo a come i dati vengono caricati nella tabella principale (chiamiamola MAIN , andando avanti). Se la tua tabella MAIN viene caricata ogni ora, sincronizzala. Ogni mezz'ora? Non importa. Puoi comunque controllare la velocità oppure, se i rapporti vengono eseguiti in prossimità delle ore non di punta, quindi programmare in prossimità di tale orario
Indicizza correttamente la tabella per i dati consolidati. Chiamiamolo AGG andare avanti.
Crea una procedura memorizzata che carichi i dati da MAIN ad AGG, che è fondamentalmente un AGG LOAD FOR INTERVAL-? . Ovviamente sei l'unico qui a sapere come o quando i dati vengono inseriti in MAIN, quindi sarai anche tu a sapere qual è l'intenzione di aggregazione. È anche possibile continuare a eseguire la stored procedure di aggregazione se l'intenzione di aggregazione non è stata completata (diciamo che è per un giorno intero.. quindi è un'esecuzione cumulativa fino a quando non viene impostata)
Usa STAGING tavoli. Per me sono i migliori .
Creare una procedura memorizzata che ricontrolla i dati, in modo che eventuali aggiornamenti o inserimenti aggiuntivi di record possano essere riflessi nella tabella AGG eseguendo questa procedura. Includere i parametri per l'intervallo da aggiornare. Se è giornaliero, hai un DAILY AGG LOAD e DAILY AGG RELOAD procedura. Includi un AGG CHECK INTERVAL e AGG CHECK DAILY procedura che ti aiuterà a dormire bene la notte. Oh e per non parlare di un AGG DATA HOLE CHECK o un MISSING AGG DATA CHECK e applicare regole aziendali che implementano il controllo di una quantità minima richiesta di dati che puoi ottenere dalla tabella aggregata o dalla tabella principale o dalla tabella di staging (preferibilmente)
Naturalmente, non modificare mai il AGG tavolo. Ricaricalo sempre e solo.
In che modo questo aiuta? Non dovresti quindi solo che i tuoi rapporti interroghino il AGG tabella, che è più piccola e più veloce (poiché l'aggregazione è già stata eseguita)? Forse il problema delle prestazioni si presenta con il caricamento a intervalli, ma se strutturi correttamente la tabella, i suoi indici e la sua manutenzione, dovrebbe valerne la pena.
Dove entra in gioco il partizionamento? Archiviazione. Trascorso un certo tempo (discutete cosa è accettabile con il vostro team/boss/top man) potete archiviare i vecchi dati da MAIN . Ho sperimentato la necessità di mantenere 1 anno di dati nel database di produzione. Sembrava un po' una seccatura, ma poiché era una richiesta del cliente, l'azienda non aveva altra scelta che darmi lo spazio su disco di cui avevo bisogno (sfregandomi le mani) e ragazzo ci ho giocato fino a quando non ho ottenuto qualcosa che funzionava decentemente. Devo dire che la mia esperienza è stata con Microsoft SQL Server 2005 e le stored procedure e SSIS lo hanno reso divertente.

Questo è tutto se non lo sai già e per altri che potrebbero voler considerare le opzioni. Non sto dicendo che tu non sapessi già nulla di quanto sopra; Sto solo affermando cosa sono stato in grado di fare prima, considerando che non avevo più informazioni su cui lavorare dal tuo post, tranne per il fatto che hai provato un processo di consolidamento..