1) Pour ce qui est de la taille de la base, c'est normal : Imagine que le fichier de la base de données est une miche de pain. Tes données, c'est la mie. Quand tu enlèves de la mie de pain, la miche garde sa taille, et il y a des trous dedans. D'un point de vue fonctionnement, c'est rigoureusement la même chose. C'est une façon d'optimiser la rapidité de la base.
Imagine, tu as une table avec 100 000 000 lignes. Chaque ligne fait mettons 4 Ko. Ca donne donc 400 000 000 000 octets, soit 400 Go (c'est une grosse base 
)
Tu supprimes une ligne à l'indice 1 (donc en début de fichier). Si MySQL "optimisait" au fur et à mesure, alors ça voudrait dire qu'il déplace 400 Go - 4 Ko dans le fichier vers le début du fichier. Je te laisse te rendre compte à quel point ce serait lent 
Par définition, un fichier de base de données ne peut donc que grossir.
Par contre, je te rassure, quand tu rajoutes des lignes, selon un certain nombre de critères, MySQL essaie de reboucher les trous.
2) Ensuite, un autoincrément "standard", se comporte comme une séquence, c'est à dire qu'il ne pourra jamais prendre une valeur qu'il a déjà affecté, même si elle n'existe plus. C'est tout à fait normal, et heureusement d'ailleurs !
Si tu veux que ton compteur reparte de la valeur X après la suppression de lignes, tu peux faire un ALTER dessus. Normalement, MySQL a aussi un mode qui bouche les trous dans un autoincrément, mais je te déconseille très fortement de l'utiliser. En effet, c'est source de problèmes dans la cohérence de ta base, et surtout, un ID n'étant pas une valeur, mais un simple compteur interne, en aucun cas tu dois te baser dessus pour de l'affichage ou autre, donc quelque soit la valeur, tu t'en moques.
Message édité par Arjuna le 25-03-2005 à 11:20:47
FORUM HardWare.fr
