Un petit tour également sur la partie 7 de la doc MySQL :
http://dev.mysql.com/doc/refman/5.1/en/ ... ation.html
avec une lecture de l'optimisation du serveur à prendre en compte.
Une partie intéressante :
http://dev.mysql.com/doc/refman/5.1/en/ ... l-use.html
The volume of data was quite huge (about seven million summary transactions per month), and we had data for 4–10 years that we needed to present to the users. We got weekly requests from our customers, who wanted instant access to new reports from this data.
We solved this problem by storing all information per month in compressed “transaction tables.” We had a set of simple macros that generated summary tables grouped by different criteria (product group, customer id, store, and so on) from the tables in which the transactions were stored.
Pour pouvoir utiliser les "grosses tables", il y a quelques règles :
1) ce ne sont pas des tables sur lesquelles on travaille quotidiennement en insert et en update. Mais ce sont des tables uniquement faites pour la lecture et qu'on remplit en batch selon une fréquence à définir.
2) Ce sont des tables dans lesquelles on embarque la totalité de l'information pour éviter d'avoir à faire des jointures. Surtout pas de 0/1/2 pour faire une jointure avec une 2e table oui/non/nsp. Ce que tu dois faire, c'est avoir une colonne code pour l'index et une colonne libellé pour l'affichage.
3) Ce sont des tables dans lesquelles on "prémache" le travail en fonction des résultats souhaités : par exemple, on prévoit et on remplit une colonne 'SOMME' pour éviter d'avoir à faire des SUM() dans les requêtes, où dans lesquelles on ajoute le champ "DEPARTEMENT" pour éviter d'avoir à faire des SUBSTR(CODEPOSTAL, 0, 2).
4) Et enfin, comme indiqué dans le texte de MySQL, ce sont des tables que l'on segmente en fonction des requêtes.
Il y a des SGBDR (par exemple Oracle) qui intègrent ce genre de mécanisme. Par exemple, soit la table des communes de France avec les populations années par années. On aura une table du style (code_commune, nom_commune, annee, population). Avec Oracle, on créera un "index partionné" sur l'année qui de manière transparente pour l'utilisateur, va créer une "pseudo-table" par année. On utilisera ensuite un index sur le code_commune.
C'est très efficace quand tu veux chercher quelle est la population des communes du 92 en 2007 puisque le moteur Oracle détectera qu'il faut utiliser la pseudo-table 2007. Par contre, ça l'est beaucoup moins si tu veux chercher l'évolution de la population d'une commune au cours des années puisque le moteur devra parcourir plusieurs "pseudo-tables".
Et si on veut connaître la population d'un département, avec Oracle on va utiliser des "vues matérialisées" qui vont calculer, au moment de l'import, les sommes des populations des communes, département par département. Donc quand tu chercheras la population d'un département, au lieu de faire la somme, Oracle ira chercher dans cette vue matérialisée qui contient déjà le résultat.
Ce genre de fonctions implémenté dans Oracle et géré automatiquement par le moteur d'optimisation n'existe pas dans MySQL. Il va donc falloir que tu fasses comme le texte de MySQL l'explique : à la main !
Quelles sont les requêtes les plus courantes que tes utilisateurs vont faire ?
Sur quels champs cela va porter et sur quelles valeurs ?
Créer des tables partielles en fonction de ces requêtes.
Imaginons que ce soit ta grosse table soit une liste de clients et que ton interface permette de faire une recherche sur le début du nom. A ce moment-là, tu crées 26 tables clientA jusqu'à clientZ et en fonction de l'initiale, ton code PHP ira lire dans la bonne table. Gain statistique : 26 fois plus rapide.
Ca va grandement accélérer les requêtes qui portent sur le nom d'un client, mais cela va ralentir une requête du type "je veux tous les clients de 2007". Donc, pour ce type de requête, tu crées des tables client2004, client2005, client2006 et ce sont elles que tu attaques quand il y a des recherches sur l'année. Voire même si c'est encore trop gros, des tables clientA2006, clientB2006, clientZ2006, clientA2007, clientZ2007, ... Et puis des tables par département, ... De toute façon, si tu manques d'espace disque, tu peux en rajouter, ce n'est pas ça le facteur économique primordial. Il faut juste que le code PHP sache ensuite quelle table attaquer en fonction du ou des critères indiqués par l'utilisateur.
C'est ce que je disais dans mes précédentes réponses : pour ce genre de problème, il n'y a pas une réponse toute faite. Cela dépend énormément de ce que tu veux faire avec les données, comment elles vont être sélectionnées, sur quels critères, ... il faut organiser les données en fonction de la ou des requêtes les plus fréquentes, quitte à dupliquer les données dans autant de tables qu'il le faut.
Et bien sûr, il te faut un script de création qui a partir de la grosse table, va effacer toutes ces tables partielles, les remettre à zéro et réinjecter des données propres.
)
