Je ne sais pas exactement ce que signifie «pertes» dans mySQL.
En tout cas, je constate systématiquement des «pertes» (affichées en dernière colonne dans phpMyAdmin) sur spip_resultats. Et pas mineurs, puisque c'est généralement aussi gros que la table elle-même. Par exemple, j'ai sous les yeux
- spip_resutats
- taille: 90,8 Kio
- pertes: 89,7 Kio.
Et c'est la seule table qui a des pertes.
Je répare la table, et j'obtiens:
- taille: 1,1 Kio
- pertes: 0.
En gros, à chaque fois que je fais un tour sur phpMyAdmin, je constate des pertes sur spip_resultats et très peu sur les autres tables (voire pas du tout).
Je dis ça je dis rien, puisque je ne sais pas ce que ça signifie.
Je ne sais pas exactement ce que signifie «pertes» dans mySQL.
il s'agit juste de l'espace inoccupé par des données effacées et qui ne
pourra être utilisé par la suite pour de nouveau stockages.
typiquement un champ de taille variable mis à jour avec des données
'plus longues'.
En tout cas, je constate systématiquement des «pertes» (affichées en dernière colonne dans phpMyAdmin) sur spip_resultats.
oui. c'est la table de stockage des recherches effectuées sur le site.
donc soumise à de fréquents remplissage/effaçage
Je répare la table, et j'obtiens:
c'est le principe de l'optimisation (optimize) de mysql :
on réécrit les données en les 'collant' les unes aux autres pour éviter
ce gaspillage d'espace (on pourrait faire un parallèle -foireux comme toujours- avec la commande 'défragmenter' des os).
la passe d'optimisation des tables est effectuée par le cron de spip
toutes les 48 heures (si je me souviens bien...)
rien de bien méchant dans tout cela et qui ne dénotte en rien un
fonctionnement anormal.
