Pourquoi cPanel et phpMyAdmin affichent des tailles différentes pour une base de données

cPanel et phpMyAdmin peuvent afficher des chiffres différents pour la même base, car la source et le moment de mise à jour dépendent de la configuration du serveur.

Vérifier la taille de la base de données dans cPanel et phpMyAdmin

• phpMyAdmin obtient depuis INFORMATION_SCHEMA l'espace alloué aux données et aux index. Avec InnoDB, ces chiffres sont approximatifs.
• cPanel peut obtenir l'utilisation depuis INFORMATION_SCHEMA ou depuis les fichiers du serveur, selon la configuration de WHM. Avec l'option par défaut, il utilise INFORMATION_SCHEMA.
• cPanel garde les tailles en cache pendant environ quatre heures.
• Avec MySQL 8, les statistiques de tables consultées par phpMyAdmin peuvent rester en cache jusqu'à 24 heures avec la configuration par défaut.

Un écart isolé ne prouve donc pas que l'un des outils mesure mal, ni que tout l'écart correspond à de l'espace physique récupérable.

Repérer les tables volumineuses

Ouvrez la base dans phpMyAdmin et triez les tables par taille. Examinez séparément Données et Index. La valeur affichée comme Perte provient de DATA_FREE : elle représente de l'espace alloué mais non occupé, sans prouver à elle seule la quantité qui peut être rendue au système d'exploitation. Dans un tablespace partagé, elle peut refléter un espace commun à plusieurs tables.

Parmi les tables que nous avons vues grossir de manière importante figurent wp_actionscheduler_actions et wp_options dans WordPress, et ps_layered_filter_block dans PrestaShop ; identifiez toutefois toujours quel composant utilise chaque table avant d'agir.

Avant de vider ou de supprimer une table, identifiez l'application qui l'utilise et faites une sauvegarde. Le nom ne suffit pas pour décider qu'elle est superflue.

Récupérer de l'espace sans endommager la base

L'opération Optimiser la table ne doit être envisagée qu'après avoir supprimé une quantité importante de données et confirmé que la table peut être réduite. Avec InnoDB, elle reconstruit généralement la table, consomme de l'espace temporaire et génère une charge disque considérable. De nombreuses tables InnoDB acceptent les écritures pendant une partie du processus, mais de brefs verrous exclusifs sont nécessaires et certains index ou configurations peuvent obliger à copier la table et à la verrouiller plus longtemps. Si la table utilise un tablespace partagé, l'opération ne garantit pas que le fichier physique du serveur diminue.

D'abord :

1. Faites une sauvegarde récente et vérifiez que vous pouvez la restaurer.
2. Supprimez depuis l'application uniquement les données dont vous n'avez plus besoin.
3. Vérifiez qu'il y a suffisamment d'espace pour l'opération.
4. N'optimisez que les tables concernées.

Les chiffres ne sont pas encore à jour

Attendez au moins le prochain recalcul de cPanel, qui a normalement lieu toutes les quatre heures. Dans phpMyAdmin, les statistiques de MySQL 8 peuvent mettre jusqu'à 24 heures à changer.

N'exécutez pas Optimiser la table uniquement pour forcer la mise à jour d'un compteur. Si l'écart persiste après ces délais, demandez une vérification en indiquant la base, les chiffres, les écrans où ils apparaissent et l'heure de la vérification. Ils pourront être comparés à l'utilisation réelle du serveur pour déterminer s'il convient de mettre à jour le cache de cPanel, sans demander d'identifiants.

Comparez toujours la même base, la même unité et le même moment : Mo et Mio ne sont pas équivalents. N'additionnez pas l'espace libre d'un tablespace partagé une fois par table. Avant une reconstruction importante, convenez d'une fenêtre de travail et d'une marge d'espace avec l'assistance ; un compteur obsolète ne justifie pas de mettre en danger une base qui fonctionne.