Vous allez certainement commencer à rencontrer des problèmes sur cette table de 42 Go une fois qu'elle ne rentre plus dans la mémoire. En effet, dès qu'il ne tient plus en mémoire, les performances se dégradent extrêmement rapidement. Une façon de tester est de mettre cette table sur une autre machine avec moins de RAM et de voir à quel point elle fonctionne mal.
Ceci est une erreur. Le partitionnement (soit via la fonctionnalité de MySQL 5.1, soit la même chose en utilisant les tables MERGE) peut offrir des avantages significatifs en termes de performances même si les tables se trouvent sur le même lecteur.
Par exemple, supposons que vous exécutez des requêtes SELECT sur votre grande table en utilisant une plage de dates. Si la table est entière, la requête sera obligée de parcourir toute la table (et à cette taille, même l'utilisation d'index peut être lente). L'avantage du partitionnement est que vos requêtes ne s'exécuteront que sur les partitions où cela est absolument nécessaire. Si chaque partition a une taille de 1 Go et que votre requête n'a besoin d'accéder qu'à 5 partitions pour se réaliser, la table combinée de 5 Go est beaucoup plus facile à gérer pour MySQL qu'une version monstrueuse de 42 Go.
Une chose que vous devez vous demander est de savoir comment vous interrogez les données. S'il est possible que vos requêtes n'aient besoin d'accéder qu'à certains blocs de données (c'est-à-dire une plage de dates ou une plage d'ID), un partitionnement quelconque s'avérera bénéfique.
J'ai entendu dire qu'il y avait encore des bogues avec le partitionnement MySQL 5.1, en particulier lié au fait que MySQL choisissait la bonne clé. Les tables MERGE peuvent fournir la même fonctionnalité, bien qu'elles nécessitent un peu plus de surcharge.
J'espère que cela aide... bonne chance !
