optimisation BDD Mysql

[comparef]

Bonjour a tous,

Dans une base de donée mySQL, dans les caracteristiques de chaque table on peut voir ceci :

Espace utilisé :
Type Espace
Données 112 Octets
Index 2 048 Octets
Perte 68 Octets
effectif 2 092 Octets
Total 2 160 Octets
[Optimiser la table]

Lorsqu'on clique sur [Optimiser la table], apparament cela suprime les pertes.
Savez-vous ce qui se passe exactement lorsqu'on clique sur [Optimiser la table] ? (que action est réalisé ?)

Merci pour vos reponses

 

[Fabrice99]

Optimize

Bonjour,

C'est la commande optimize qui est utilisée.
Elle permet de défragmenter la base de données et de récuperer de l'espace non utilisé après effacement ou modification d'enregistrements.

Vous trouverez plus d'informations sur le site officiel de Mysql :
http://dev.mysql.com/doc/mysql/fr/optimize-table.html

 

[comparef]

ok, merci pour ta réponse

 

[JeunZ]

Quand tu as une grosse base de donnée très utilisée (ajout d'enregistrement, delete etc...) utilise cette commande régulièrement pour que les accès soient plus rapide et récuperer l'espace perdu...

 

[doic]

Moi j'en profite pour demander si quelqu'un connait un moyen de toujours donner le bon type à un champ MySQL en fonction de ce qu'il va contenir...
Ex: Text, VarChar, Int, Bigint etc... et aussi évidemment comment calculer les tailles de ces champs?

Le truc qui serait génial, ce serait un script qui "crawle" ma base et me génère un rapport avec les modifications à entreprendre...

Merci ;-)

 

[JeunZ]

Moi je le fait sans script précis... Je veux dire c'est pas compliqué.

Quand tu fais la structure de ta base de donnée tu sais par exemple que ca va etre un int qui prendra soit la valeur 0 ou 1 tu lui fou alors la taille 1, si c'est un int qui s'autoincrémente tu réflechis à combien il pourra y avoir en gros d'enregistrement dans X temps...

Pour les varchar ba il doit y avoir des tailles standart genre pour les emails, adresses etc...

Un code postale c'est une taille de 5 par exemple etc...

Pas besoin de script je crois.

 

[Patrice A.]

C'est très très simple.
Une fois ta base arrivée à une taille "de croisière" (c'est-à-dire qu'elle contient assez de données pour qu'on puisse se faire une idée de l'état optimum des types des champs), tu passes par phpMyadmin, et tu utilises la fonction Suggérer des optimisations pour cette table qui va faire exactement ce que tu demandes : analyser la table et t'informer des meilleurs choix.

 

[doic]

OK, et comment savoir si on prend un varchar ou un text? etc?

 

[Vell]

Justement pour les très grosses bases ça devient intéressant au niveau du temps d'execution qui pourrait changer selon un char(1) et un int(1).
De quelques centièmes certes, mais multipliés par des milliers voire millions de fois, ça fait une sacré perte de temps.

Donc oui, un script pourrait être utile. Ou alors regarder dans la doc mysql ce qui est le plus adapté, et les commentaires aussi. Y'a des tas de bons trucs à prendre dans les com... (et des mauvais aussi, mais c'est assez rare)

 

[Patrice A.]

Donc oui, un script pourrait être utile.

OK, et comment savoir si on prend un varchar ou un text? etc?

j'ai vraiment l'impression d'avoir parlé dans le vide là... rassurez-moi vous avez lu ce que j'ai posté au-dessus hein ?

 

[doic]

Et non Dj!
Je viens de capter ton message, on a posté en même temps!!
Je fonce sur PhpMyAdmin pour voir cette fonction magique!!!

 

[doic]

C'est GENIALEUH!!!

Je m'occupe de ça le plus vite possible et je regarde si ça me réduit le poids de ma base de beaucoup ou pas...

Merci Dj_Apx!!

 

[Patrice A.]

Oh, pour le poids, tu ne gagneras rien, ou pas grand-chose. Mais la rapidité peut vraiment être améliorée par cette analyse.
Attention cependant à n'utiliser le type ENUM que si on est vraiment sûr que les valeurs du champ appartiennent à un ensemble discret, fini, et connu.

 

[doic]

J'ai pas mal de champs qui fonctionnent en binaire (NULL ou 1) et je pense que ce type de champ devrait correspondre, non? en tout cas c'est ce que me propose PhpMyAdmin...

 

[comparef]

lorsque je créé une table, le prevoi toujours 2 champs en plus (que je nome par exemple "reserve1" et "reserve2".
Car il est fréquent que je soit obligé de rajouter des champs apres coup.
cela m'evite donc de reprogrammer mes requetes lorsque je rajoute un ou 2 champs.

Au niveau de l'optimisation (vitesse d'execution et poids) cette technique est-elle à proscrire ?

 

[Patrice A.]

Si tu fais correctement tes insertions, tu peux rajouter des champs en fin de liste indéfiniment, et les requêtes fonctionnent toujours.

C'est donc inutile.

 

[comparef]

En fait j'utilise ce type de requete :

	$requete=mysql_db_query($sql_bdd,"insert into TABLE values ('valeur1','valeur2','valeur3','valeur4','valeur5','valeur6','valeur7')",$db_link) or die(mysql_error());

donc si apres coup je rajoute un champs ca bug.

 

[Patrice A.]

rajoute le nom des champs dans lesquels tu insères, c'est plus propre et ça marchera même si tu changes l'ordre des champs ou si tu en rajoutes.

Pour connaître la "bonne syntaxe", fais une insertion avec phpMyadmin et récupère la requête SQL affichée

 

[comparef]

Merci,

oui c'est vrai que l'ecriture dont tu parle est mieux,
j'utilise celle que j'ai mis plus haut plus par habitude qu'autre chose (habitude quand tu nous tien....)

Je vai utiliser la tienne a l'avenir, ca evitera des champs inutiles dans mes tables...

 

[Vell]

Et c'est très pratique pour les utilisations des valeurs par défaut, plutôt que de donner la valeur (si elle est égale à la valeur par défaut).
C'est plus rapide au niveau temps d'insertion

 

[doic]

Ouep...
Petite question: PhpMyAdmin me suggère un peu trop souvent d'utiliser des types 'enum', même lorsque je peux avoir une centaine de valeurs...
Pour l'instant, je préfère mettre des int(2), pour ne pas m'embêter, mais est-ce qu'en théorie un enum('0','1','2',...,'98','99') va être plus rapide à gérer qu'un int(2)?

 

[Vell]

Là je sais pas, par contre au niveau place ce sera certainement meilleur.
Qui dit moins de place, dit aussi (toujours en théorie) plus rapide à exécuter...

Donc à voir, faut tester

 

[comparef]

je me demandais aussi,
est il preferable de répartir toutes les tables dans plusieurs bases de données (mon hebergeur m'en autorise 5 je croi).
par exemple mettre toutes les tables concernant le forum dans une certaine base, toutes les tables concernant le corp du site dans une autre base, etc...
et a partir de combien de table (ou combien de Mo) est il vraiment necessaire de recourire a plusieurs bases de données ?

 

[Vell]

1 - Comme le précise la documentation, le plus long est d'avoir le premier bit de la ligne, donc il vaut mieux avoir une "grosse" table plutôt que plusieurs petites.
Note : comme la doc le précise encore, il faut séparer si on utilise souvent qu'une seule partie (ou plusieurs, mais différemment) de ces données.

2 - A partir de la remarque précédente, on peut alléger le nombre de tables dans une bdd.

3 - Ca peut être une bonne idée, j'y songe également à cause des perf.

4 - A partir de 5 ou 6 go tu peux passer sur une autre bdd histoire d'être tranquille, sinon ça devrait passer sans soucis quand même.