Si vous parlez de plus gros volumes de données, alors regardez Partitionnement MySQL . Pour ces tables, une partition par données/temps aiderait certainement les performances. Il y a un article décent sur le partitionnement ici .
Envisagez de créer deux bases de données distinctes :une pour toutes les données brutes pour les écritures avec une indexation minimale ; une seconde pour les rapports utilisant les valeurs agrégées ; avec soit un traitement par lots pour mettre à jour la base de données de rapports à partir de la base de données de données brutes, soit utiliser la réplication pour le faire pour vous.
MODIFIER
Si vous voulez être vraiment intelligent avec vos rapports d'agrégation, créez un ensemble de tableaux d'agrégation ("aujourd'hui", "semaine à ce jour", "mois à ce jour", "par année"). Agréger des données brutes à « aujourd'hui », soit quotidiennement, soit en « temps réel » ; regrouper de « par jour » à « semaine à ce jour » sur une base nocturne ; de "semaine à ce jour" à "mois à ce jour" sur une base hebdomadaire, etc. Lors de l'exécution de requêtes, joignez (UNION) les tables appropriées pour les plages de dates qui vous intéressent.
MODIFICATION #2
Plutôt qu'une table par client, nous travaillons avec un schéma de base de données par client. Selon la taille du client, nous pouvons avoir plusieurs schémas dans une seule instance de base de données, ou une instance de base de données dédiée par client. Nous utilisons des schémas distincts pour la collecte de données brutes et pour l'agrégation/la création de rapports pour chaque client. Nous gérons plusieurs serveurs de base de données, limitant chaque serveur à une seule instance de base de données. Pour la résilience, les bases de données sont répliquées sur plusieurs serveurs et la charge est équilibrée pour de meilleures performances.
