tabla mysql muy grande e informes

Comience por buscar en partition ing su tabla si aún no lo ha hecho:

¿Cómo está 'consolidando' sus datos? Tal vez el método que está utilizando no es óptimo. Un buen enfoque (déjeme saber si esto es realmente lo que está haciendo) es crear una tabla que contenga datos agregados. Luego configúralo de esta manera:

Primero, dejando de lado cómo se vierten los datos en su tabla principal...

Cree un trabajo (cron o lo que tenga a mano o ya configurado) que se ejecute en un intervalo específico, en relación con la forma en que se cargan los datos en la tabla principal (llamémoslo MAIN , avanzando). Si su tabla PRINCIPAL se carga cada hora, sincronícela. ¿Cada media hora? No importa Puede verificar la velocidad de todos modos, o si sus informes se ejecutan cerca de las horas de menor actividad, luego programe cerca de ese momento
Indexe correctamente su tabla para obtener datos consolidados. Llamémoslo AGG avanzando.
Cree un procedimiento almacenado que cargue datos de MAIN a AGG, que es básicamente un AGG LOAD FOR INTERVAL-? . Por supuesto, usted es el único aquí que sabe cómo o cuándo se insertan los datos en MAIN, por lo que también será quien sepa cuál es la intención de agregación. También es posible seguir ejecutando el procedimiento almacenado de agregación si la intención de agregación no se completa (digamos que es para un día completo... por lo que es una ejecución acumulativa hasta que se establezca)
Usa STAGING mesas. Para mí, son los mejores .
Cree un procedimiento almacenado que vuelva a verificar los datos, de modo que cualquier actualización o inserción adicional de registros pueda reflejarse en la tabla AGG al ejecutar este procedimiento. Incluya parámetros para que el rango se actualice. Si es diario, entonces tiene una DAILY AGG LOAD y DAILY AGG RELOAD procedimiento. Incluya un AGG CHECK INTERVAL y AGG CHECK DAILY procedimiento que le ayudará a dormir bien por la noche. Ah, y sin mencionar una AGG DATA HOLE CHECK o un MISSING AGG DATA CHECK y aplique reglas comerciales que implementen la verificación de una cantidad mínima requerida de datos que puede obtener de la tabla agregada o de la tabla principal o la tabla provisional (preferiblemente)
Por supuesto, nunca modifiques el AGG mesa. Siempre solo recárgalo.
¿Cómo ayuda esto? Entonces, ¿no solo necesitaría que sus informes consulten el AGG tabla, que es más pequeña y más rápida (dado que la agregación ya se ha hecho)? Tal vez el problema de rendimiento viene con la carga del intervalo, pero si estructura correctamente su tabla, sus índices y su mantenimiento, debería valer la pena.
¿Dónde entra la partición? archivado. Una vez que haya pasado cierto tiempo (discuta lo que es aceptable con su equipo/jefe/jefe) puede archivar los datos antiguos desde MAIN . Experimenté tener que mantener los datos de 1 año en la base de datos de producción. Eso me pareció un poco pesado, pero debido a que era la solicitud del cliente, la compañía no tuvo más remedio que darme el espacio en disco que necesitaba (se frota las manos) y jugué con él hasta que conseguí que algo funcionara decentemente. Debo mencionar que mi experiencia fue con Microsoft SQL Server 2005, y los procedimientos almacenados y SSIS lo hicieron divertido.

Esto es todo si aún no lo sabe, y para otros que quieran considerar opciones. No estoy diciendo que no sabías nada de lo anterior ya; Solo digo lo que pude hacer antes, considerando que no tenía más información con la que trabajar de su publicación, excepto que tiene un proceso de consolidación que probó.