très grande table mysql et rapports

Commencez par examiner partition votre tableau si vous ne l'avez pas déjà fait :

Comment « consolidez-vous » vos données ? Peut-être que la méthode que vous utilisez n'est pas optimale. Une bonne approche (faites-moi savoir si c'est réellement ce que vous faites) consiste à créer un tableau contenant des données agrégées. Ensuite, configurez-le de cette façon :

Tout d'abord, mettez de côté la façon dont les données sont déversées dans votre table principale...

Créez une tâche (cron ou tout ce que vous avez sous la main ou déjà configuré) qui s'exécute à un intervalle spécifié, par rapport à la façon dont les données sont chargées dans la table principale (appelons-la MAIN , avancer). Si votre table MAIN est chargée toutes les heures, synchronisez-la. Demi-heure ? Peu importe. Vous pouvez quand même vérifier la vitesse, ou si vos rapports sont exécutés près des heures creuses, alors programmez-les à peu près
Indexez correctement votre table pour les données consolidées. Appelons-le AGG aller de l'avant.
Créez une procédure stockée qui charge les données de MAIN vers AGG, qui est essentiellement un AGG LOAD FOR INTERVAL-? . Bien sûr, vous êtes le seul ici à savoir comment ou quand les données sont insérées dans MAIN, vous serez donc également celui qui sait quelle est l'intention d'agrégation. Il est également possible de continuer à exécuter la procédure stockée d'agrégation si l'intention d'agrégation n'est pas terminée (disons que c'est pour une journée entière... il s'agit donc d'une exécution cumulative jusqu'à ce qu'elle soit définie)
Utilisez STAGING les tables. Pour moi, ce sont les meilleurs .
Créez une procédure stockée qui revérifie les données, afin que toute mise à jour ou insertion supplémentaire d'enregistrements puisse être reflétée dans la table AGG en exécutant cette procédure. Incluez les paramètres de la plage à mettre à jour. Si c'est quotidien, alors vous avez une DAILY AGG LOAD et DAILY AGG RELOAD procédure. Inclure un AGG CHECK INTERVAL et AGG CHECK DAILY procédure qui vous aidera à bien dormir la nuit. Oh et sans parler d'un AGG DATA HOLE CHECK ou un MISSING AGG DATA CHECK et appliquez des règles métier qui implémentent la vérification d'une quantité minimale requise de données que vous pouvez obtenir à partir de la table agrégée ou de la table principale ou de la table intermédiaire (de préférence)
Bien sûr, ne modifiez jamais le AGG table. Toujours le recharger uniquement.
Comment cela aide-t-il ? N'auriez-vous pas alors seulement besoin que vos rapports interrogent l'AGG table, qui est plus petite et plus rapide (puisque l'agrégation a déjà été faite) ? Peut-être que le problème de performances vient du chargement par intervalle, mais si vous structurez correctement votre table, ses index et sa maintenance, cela devrait en valoir la peine.
D'où vient le partitionnement? Archivage. Une fois qu'un certain temps s'est écoulé (discutez de ce qui est acceptable avec votre équipe/boss/top man), vous pouvez archiver les anciennes données de MAIN . J'ai dû conserver 1 an de données dans la base de données de production. Cela ressemblait un peu à un frein, mais parce que c'était la demande du client, la société n'avait d'autre choix que de me donner l'espace disque dont j'avais besoin (se frotte les mains) et j'ai joué avec jusqu'à ce que quelque chose fonctionne correctement. Je dois mentionner que mon expérience était avec Microsoft SQL Server 2005, et les procédures stockées et SSIS l'ont rendu amusant.

C'est tout si vous ne le savez pas déjà, et pour les autres qui voudront peut-être envisager des options. Je ne dis pas que vous ne connaissiez pas déjà tout ce qui précède ; Je ne fais qu'indiquer ce que j'ai pu faire auparavant - étant donné que je n'avais pas plus d'informations avec lesquelles travailler à partir de votre message, sauf que vous avez un processus de consolidation que vous avez essayé..