Taille d'une table MySQL

Version imprimable

23/08/2006, 12h49
chnain

Taille d'une table MySQL

Une question concernant la taille des tables MySQL. Certaines des tables que j'utilise sont très grosses en taille et en nombre de ligne. Par ex. l'une d'elle fait plus de 5 millions de lignes et 510M. A partir de quel moment la taille d'une table risque de devenir un vrai problème?

En outre, lorsque cela est possible, est-il intéressant de spliter en plusieurs les tables qui grossissent? Par exemple, sortir les infos d'abonnement de la table des membres pour le lire avec un LEFT JOIN?

Inversement, lorsque l'on lit une dizaine de tables différentes regroupant des infos de même type, est-ce intéressant des les réunir en une seule en y ajoutant simplement une colonne donnant le type d'info lue, au risque de se retrouver avec une table 10 fois plus volumineuse qu'une seule de ces 10 tables?

Merci.
23/08/2006, 14h29
Biglo

Citation:

Envoyé par chnain

Une question concernant la taille des tables MySQL. Certaines des tables que j'utilise sont très grosses en taille et en nombre de ligne. Par ex. l'une d'elle fait plus de 5 millions de lignes et 510M. A partir de quel moment la taille d'une table risque de devenir un vrai problème?

Ca dépend de tes requêtes, de la charge du serveur, etc. Dans un grand nombre de cas, si tes index sont bien placés et tes requêtes formulées correctement, même si ta table triple de volume, ça ne devrait pas poser de problèmes.

Citation:

Envoyé par chnain

En outre, lorsque cela est possible, est-il intéressant de spliter en plusieurs les tables qui grossissent? Par exemple, sortir les infos d'abonnement de la table des membres pour le lire avec un LEFT JOIN?

Ca peut apporter un gain conséquent, surtout si l'accès à ces infos sont rares et si elles prennent réellement de la place. Tu peux jeter un oeil à l'exemple ici pour te faire une idée : http://krierjon.developpez.com/mysql...tionnement/#L3

Citation:

Envoyé par chnain

Inversement, lorsque l'on lit une dizaine de tables différentes regroupant des infos de même type, est-ce intéressant des les réunir en une seule en y ajoutant simplement une colonne donnant le type d'info lue, au risque de se retrouver avec une table 10 fois plus volumineuse qu'une seule de ces 10 tables?

Je n'ai pas très bien saisi là, désolé... Un exemple peut-être ?
23/08/2006, 15h14
chnain

Citation:

Envoyé par Biglo

Je n'ai pas très bien saisi là, désolé... Un exemple peut-être ?

Je te donne un exemple : j'ai 11 tables qui sauvegardent les films préférés, les albums, les livres, etc., des utilisateurs, avec les colonnes identifiant_de_loeuvre, identifiant_du_membre et date_dajout. Ces tables font en moyenne 20 000 lignes.
Je pourrais faire une seule table de "préférences" en ajoutant à la clé primaire une colonne "type d'objet".
Mais j'hésite : cela va me faire une grosse table, qui de plus est souvent utilisée.

Merci de ta réponse!

chnain
23/08/2006, 15h31
Biglo

Ok. Dans ce cas, il faut voir comment tu accèdes aux préférences d'un utilisateur. Par exemple, si tu fais des requêtes qui concernent aussi bien les films que les albums et les livres préférés, stocker tout dans une seule table ne devrait pas trop gêner. Bien que pour l'affichage dans l'application, il te faudra sûrement grouper les livres ensembles, ce qui est un peu plus coûteux que si tout était dans des tables séparées.

Par contre, si tu fais des requêtes qui ne concernent qu'un seul type de préférence (WHERE typePref = Livre par exemple), j'opterais sans hésitation pour les tables séparées. Car si toutes les préférences sont ensemble, la taille de la table risquera réellement de ralentir tes requêtes. Bien que 220 000 lignes ne soit pas vraiment énorme ;)
23/08/2006, 16h52
chnain

Citation:

Envoyé par Biglo

Ok. Dans ce cas, il faut voir comment tu accèdes aux préférences d'un utilisateur. Par exemple, si tu fais des requêtes qui concernent aussi bien les films que les albums et les livres préférés, stocker tout dans une seule table ne devrait pas trop gêner. Bien que pour l'affichage dans l'application, il te faudra sûrement grouper les livres ensembles, ce qui est un peu plus coûteux que si tout était dans des tables séparées.

Par contre, si tu fais des requêtes qui ne concernent qu'un seul type de préférence (WHERE typePref = Livre par exemple), j'opterais sans hésitation pour les tables séparées. Car si toutes les préférences sont ensemble, la taille de la table risquera réellement de ralentir tes requêtes. Bien que 220 000 lignes ne soit pas vraiment énorme ;)

Pour te répondre rapidement, les tables sont utilisées par endroit une par une, et par endroit toutes en même temps, par un ensemble de LEFTJOIN! Donc pas facile de faire un choix...
:cry:
23/08/2006, 17h06
Biglo

Elles sont utilisées ensemble et séparemment pour un utilisateur donné ? Si c'est le cas, un index sur toutes les colonnes idUtilisateur sera suffisamment performant pour réaliser les jointures ;)
23/08/2006, 18h43
chnain

Citation:

Envoyé par Biglo

Elles sont utilisées ensemble et séparemment pour un utilisateur donné ? Si c'est le cas, un index sur toutes les colonnes idUtilisateur sera suffisamment performant pour réaliser les jointures ;)

C'est déjà le cas. En tout cas merci de ton aide. Je crois que le mieux serait de tester les 2 solutions, mais cela va prendre du temps.