Tables de la base de données indisponibles : réparer WordPress

Une ou plusieurs tables de votre base de données sont indisponibles. La base de données a peut-être besoin d’être réparée.

En anglais : One or more database tables are unavailable. The database may need to be repaired.

Votre site affiche soudain un message disant qu’une ou plusieurs tables de la base de données sont indisponibles et qu’il faudrait la réparer. Selon l’endroit, vous verrez ce texte complet (dans l’administration, ou lors de l’installation) ou le message plus bref « Erreur lors de la connexion à la base de données » sur les pages publiques. Dans les deux cas, WordPress réussit à joindre le serveur MySQL ou MariaDB, mais ne parvient pas à lire une de ses propres tables.

C’est une situation sérieuse mais rarement fatale : dans la majorité des cas, une table abîmée après une coupure ou un disque plein se répare en quelques secondes. Le plus important est de sauvegarder avant d’agir.

Ce que signifie cette erreur

Au démarrage, WordPress appelle is_blog_installed() (wp-includes/functions.php) pour savoir si le site est installé. La fonction cherche l’option siteurl dans la table des options. Si elle ne peut pas la lire, elle exécute DESCRIBE sur chacune des tables du cœur. Aucune table n’existe : le site est considéré comme vierge et WordPress redirige vers l’installateur (wp_not_installed(), wp-includes/load.php). Au moins une table existe : le site a été installé, mais une table est illisible. WordPress prépare alors le message ci-dessus, avec un lien vers maint/repair.php, puis appelle dead_db().

Cette dernière fonction affiche le texte détaillé uniquement dans l’administration ou pendant l’installation ; ailleurs, elle se contente de « Erreur lors de la connexion à la base de données » (titre « Erreur de la base de données »). Si le dossier wp-content/ contient un fichier db-error.php, c’est lui qui est affiché à la place.

Le script de réparation se trouve dans wp-admin/maint/repair.php. Il est volontairement inactif tant que la constante WP_ALLOW_REPAIR n’est pas définie à true dans wp-config.php. Une fois la constante activée, il exécute CHECK TABLE sur chaque table, puis REPAIR TABLE sur celles qui sont en défaut, et propose en option de les optimiser. Important : cette page ne demande aucune connexion ; il faut donc retirer la constante dès que vous avez terminé.

Diagnostic rapide

Symptôme / constat	Cause probable	À vérifier
Le message apparaît après une coupure de courant, un redémarrage forcé ou un plantage du serveur	Table corrompue (surtout en MyISAM)	Journal d’erreurs de MySQL : « marked as crashed »
L’erreur survient pendant qu’un import ou une sauvegarde est en cours	Interruption, disque saturé	Espace disque (df -h), taille du dossier de la base
Le site redirige vers wp-admin/install.php	Aucune table trouvée : mauvais préfixe ou base vide	$table_prefix dans wp-config.php, liste des tables
Seuls certains écrans échouent, avec « Erreur de la base de données WordPress » et un nom de table	Table précise endommagée	Nom de la table dans le message ou debug.log
La page de réparation dit « The storage engine for the table doesn’t support repair »	Table InnoDB : REPAIR TABLE inapplicable	Moteur de la table (SHOW TABLE STATUS)
Le message revient après chaque réparation	Problème matériel, disque défaillant ou base trop grosse pour le serveur	Hébergeur, journal système, S.M.A.R.T.

Les causes les plus fréquentes

1. Un arrêt brutal du serveur (coupure électrique, redémarrage forcé, processus tué) qui interrompt une écriture ; les tables MyISAM sont les plus exposées.
2. Un disque ou un quota saturé : MySQL ne peut plus écrire et laisse des tables dans un état incohérent.
3. Un plantage de MySQL ou de MariaDB, souvent causé par un manque de mémoire.
4. Un import ou une migration interrompus, qui laissent une base à moitié restaurée.
5. Un défaut du disque ou du système de fichiers, plus rare mais à ne pas écarter si l’erreur se répète.
6. Un mauvais préfixe de tables après un déplacement : WordPress cherche des tables qui n’existent pas sous ce nom.

Solutions pas à pas

Sauvegardez d’abord. Une réparation peut supprimer des lignes irrécupérables. Du moins invasif au plus technique :

1. Sauvegarder la base et vérifier les ressources

Exportez la base, depuis phpMyAdmin ou en ligne de commande. Même une base endommagée s’exporte souvent en grande partie :

mysqldump -u UTILISATEUR -p NOM_DE_LA_BASE > sauvegarde-avant-reparation.sql
df -h

La commande df -h vérifie qu’il reste de la place. Si l’export échoue sur une table précise, notez son nom. Si le serveur MySQL est inaccessible, voir la fiche connexion à la base de données. Sur un mutualisé, demandez à l’hébergeur une copie de la base si l’export échoue.

2. Réparer avec l’outil de WordPress

C’est la solution prévue par le cœur, utilisable sans WP-CLI ni phpMyAdmin. Ajoutez cette ligne à wp-config.php, au-dessus de « That’s all, stop editing! » :

define( 'WP_ALLOW_REPAIR', true );

Ouvrez ensuite https://www.exemple.fr/wp-admin/maint/repair.php. Cliquez sur « Réparer la base de données » (ou « Réparer et optimiser la base de données »). L’écran liste chaque table : « La table wp_options est correcte. » ou, en cas de problème, la tentative de réparation. En cas d’échec, il affiche « Impossible de réparer la table … » avec le message de MySQL. À la fin, WordPress vous demande de retirer la ligne de wp-config.php : faites-le immédiatement, car la page est accessible à tous tant que la constante existe.

3. Réparer avec WP-CLI

Si vous avez un accès SSH, les commandes suivantes fonctionnent même quand le site affiche l’erreur :

wp db check
wp db repair
wp db optimize

wp db check teste toutes les tables, wp db repair lance la réparation et wp db optimize les optimise. Relancez wp db check pour confirmer que tout est « OK ».

4. Réparer avec phpMyAdmin ou en SQL

Dans phpMyAdmin, ouvrez la base, cochez les tables en défaut (ou toutes), puis choisissez « Réparer la table » dans le menu « Avec la sélection ». En SQL, pour la table des options :

CHECK TABLE wp_options;
REPAIR TABLE wp_options;

En ligne de commande, mysqlcheck -u UTILISATEUR -p --auto-repair --check NOM_DE_LA_BASE traite toutes les tables d’un coup. Le détail d’un cas réel (table wp_posts marquée comme corrompue après une coupure) se trouve dans l’article Table WordPress corrompue après une coupure serveur.

5. Cas des tables InnoDB

REPAIR TABLE ne s’applique pas aux tables InnoDB, le moteur par défaut des installations récentes. InnoDB sait se rétablir seul après un arrêt non propre ; si une table reste illisible, reconstruisez-la ou restaurez-la :

ALTER TABLE wp_options ENGINE=InnoDB;

Si le serveur refuse même de démarrer ou de lire la table, il faut passer par une restauration complète depuis une sauvegarde. Les administrateurs expérimentés peuvent aussi démarrer MySQL avec innodb_force_recovery (valeur 1 à 6 dans la section [mysqld] de my.cnf) pour exporter les données, puis recréer la base ; sur un hébergement partagé, confiez cette étape au support. Si vous utilisez encore MyISAM, envisagez la conversion décrite dans Migrer une base WordPress de MyISAM vers InnoDB.

6. Restaurer une sauvegarde

Si la réparation échoue ou si des données manquent, restaurez la dernière sauvegarde saine :

mysql -u UTILISATEUR -p NOM_DE_LA_BASE < sauvegarde-saine.sql

Importer écrase les tables existantes portant le même nom ; assurez-vous donc d’avoir mis de côté l’état actuel (étape 1). Un bon plan de reprise est décrit dans l’article sur les sauvegardes et le plan de reprise.

Sans accès à l’administration

Les solutions 2, 3 et 4 n’exigent aucune connexion à WordPress : modification de wp-config.php par SFTP, SSH avec WP-CLI, ou phpMyAdmin depuis le panneau de l’hébergeur.

Prévenir l’erreur

• Automatisez les sauvegardes de la base et testez régulièrement leur restauration.
• Passez vos tables en InnoDB : le moteur est transactionnel et supporte les arrêts brutaux.
• Surveillez l’espace disque et la mémoire du serveur, qui provoquent la plupart des corruptions.
• Ne laissez pas WP_ALLOW_REPAIR activé en dehors d’une réparation.
• Évitez de couper un import en cours, et travaillez sur une copie quand vous restaurez une grosse base.

Questions fréquentes