Réparer une base WordPress corrompue pas à pas

Si vous avez déjà vu “Table ‘wp_options’ is marked as crashed and should be repaired” dans vos logs à 2h du matin, vous savez que “réparer la base” peut vouloir dire trois choses différentes. Selon le moteur (InnoDB vs MyISAM), la corruption n’a pas la même cause, et les mêmes commandes peuvent être soit salvatrices, soit dangereuses.

Le problème

Les erreurs de base de données corrompue se manifestent souvent par des pages blanches, des erreurs 500, des requêtes lentes, ou des erreurs SQL explicites. Voici des messages réels que je vois régulièrement sur des sites WordPress 6.9.4 (PHP 8.1+) après un crash serveur, une saturation disque, une restauration incomplète ou un arrêt brutal du conteneur Docker.

WordPress database error Table 'wp_options' is marked as crashed and should be repaired for query SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes' made by require('wp-blog-header.php')

WordPress database error Can't open file: './db/wp_posts.MYD' (errno: 145) for query SELECT ID, post_title FROM wp_posts WHERE post_status='publish'

ERROR 144 (HY000): Table './db/wp_postmeta' is marked as crashed and last (automatic?) repair failed

InnoDB: Database page corruption on disk or a failed file read of page [page id: space=123, page number=456]
InnoDB: Assertion failure in thread ...

Où ça apparaît :

Front-end : pages qui renvoient 500/502, ou chargement infini si une requête bloque.
wp-admin : impossibilité de se connecter, écran blanc sur “Extensions”, erreurs lors de l’enregistrement.
WP-Cron : tâches qui s’empilent, mails non envoyés, imports bloqués.
REST API / AJAX : erreurs 500 sur /wp-json/..., éditeur de blocs instable, Elementor qui boucle sur “Loading”.

Circonstances typiques :

Redémarrage brutal de MySQL/MariaDB (OOM, crash kernel, mise à jour forcée).
Disque plein (le plus fréquent en mutualisé), puis “nettoyage” et redémarrage.
Restauration d’un dump incomplet ou compressé corrompu.
Copie manuelle de fichiers .frm/.ibd (à éviter).
Migration hâtive (changement de préfixe, import partiel, encodage incohérent).

À la fin, vous saurez :

Identifier le moteur des tables (InnoDB/MyISAM) et choisir la bonne stratégie.
Réparer proprement via WP-CLI et comprendre ce que fait WordPress.
Utiliser phpMyAdmin quand c’est pertinent (et éviter les faux “repairs”).
Décider quand il faut restaurer plutôt que “réparer”.
Valider la correction (tests, logs, Query Monitor, intégrité).

Résumé rapide

Commencez par une sauvegarde (dump SQL + fichiers) avant toute réparation.
MyISAM : REPAIR TABLE peut sauver la mise. InnoDB : souvent, il faut restaurer ou corriger côté serveur.
WP-CLI : utilisez wp db check puis wp db repair (et ensuite wp db optimize) pour un flux reproductible.
phpMyAdmin : utile pour un diagnostic rapide, mais attention aux “réparations” qui masquent le vrai problème (disque, crash InnoDB).
Si l’erreur revient après réparation : suspectez le stockage (disque), la RAM, un MySQL instable, ou un conteneur qui tue mysqld.
Validez avec logs MySQL, Query Monitor, et une batterie de requêtes WordPress (admin, REST, cron).

Les symptômes

Vous n’aurez pas toujours un message SQL clair. Voici les symptômes que j’associe le plus souvent à une corruption (ou à un problème de stockage qui y mène).

Erreur 500/502 aléatoire, parfois seulement sur certaines pages (requêtes spécifiques).
Écran blanc sur wp-admin, surtout sur le tableau de bord (chargement d’options autoload).
Connexion impossible (lecture/écriture de wp_users / wp_usermeta échoue).
REST API : l’éditeur de blocs affiche “La réponse n’est pas une réponse JSON valide”.
AJAX : Elementor/Divi/Avada ne sauvegarde plus, ou renvoie 500 sur admin-ajax.php.
WP-Cron : wp cron event run --due-now renvoie des erreurs DB, les tâches restent “due”.
Performances : pics CPU MySQL, requêtes qui “hang” (table lock MyISAM, ou InnoDB en recovery).
Erreurs dans debug.log : “marked as crashed”, “Incorrect key file”, “InnoDB: page corruption”.

Tableau de diagnostic rapide

Symptôme	Cause probable	Vérification	Solution
“marked as crashed”	Table MyISAM corrompue (arrêt brutal, disque plein)	`wp db check` + vérifier ENGINE=MyISAM	`wp db repair` ou `REPAIR TABLE`
“InnoDB: page corruption”	Corruption InnoDB / stockage instable	Logs MySQL/MariaDB, `SHOW ENGINE INNODB STATUS`	Restaurer snapshot, corriger infra, parfois `innodb_force_recovery`
Admin lent, autoload énorme	`wp_options` gonflé + index/fragmentation	Query Monitor, taille autoload	Optimisation + nettoyage ciblé (après réparation)
Erreur uniquement sur certaines pages	Une table spécifique (postmeta, termmeta) corrompue	Ré-exécuter la requête fautive, vérifier table	Réparer/restaurer la table, reconstruire index
Ça “répare” puis re-casse	Disque plein, permissions, crash mysqld, container kill	dmesg, logs, monitoring, espace disque	Corriger la cause racine + restaurer proprement

Pourquoi ça arrive

Version simple : WordPress lit et écrit dans MySQL/MariaDB. Si le serveur s’arrête au mauvais moment, si le disque renvoie des erreurs, ou si une table est dans un format fragile (MyISAM), les fichiers de table peuvent se désynchroniser. WordPress ne “corrompt” pas la base tout seul ; il révèle un problème de persistance.

Version technique : la stratégie dépend du moteur.

MyISAM : tables non transactionnelles, sensibles aux arrêts brutaux. Les fichiers .MYD/.MYI se corrompent, et REPAIR TABLE peut reconstruire les index. C’est la corruption “réparable” la plus classique.
InnoDB : transactionnel, crash recovery. Une vraie corruption InnoDB (pages) est souvent un symptôme de stockage défaillant, d’un bug serveur, ou d’un dump/restauration incohérent. Les “repairs” SQL ne suffisent généralement pas.

Causes probables (du plus fréquent au plus rare), dans mon expérience :

Disque plein (temp files MySQL, binlogs, backups) puis redémarrage.
Arrêt brutal (OOM killer, reboot forcé, mise à jour kernel, crash hyperviseur).
Migration : import interrompu, mauvais encodage, tables partielles.
MyISAM hérité : vieux sites, anciennes tables de plugins, ou migrations partielles vers InnoDB.
Stockage instable : erreurs I/O, volume réseau, snapshots cassés.
Bug MariaDB/MySQL (rare, mais arrive sur versions spécifiques) ; d’où l’importance d’aligner les versions et de lire les changelogs.

Prérequis avant de commencer

Avant de lancer une réparation, sécurisez votre capacité de retour arrière. J’ai vu des “REPAIR TABLE” transformer une corruption partielle en perte de lignes, surtout sur des tables MyISAM de gros sites.

WordPress : 6.9.4 (ou plus récent), cohérent avec la base.
PHP : 8.1+ recommandé (et cohérent avec vos extensions).
Accès : SSH (WP-CLI) idéal ; sinon phpMyAdmin.
Outils :
- Query Monitor pour identifier la requête fautive et les erreurs DB.
- Health Check & Troubleshooting pour isoler un conflit sans casser le site pour les visiteurs.

Activer les logs WordPress (sans vous tirer une balle dans le pied)

Sur un site en panne, vous pouvez activer le debug temporairement. Ne laissez pas WP_DEBUG_DISPLAY à true en production.

<?php
// wp-config.php — à placer au-dessus de "/* That's all, stop editing! */"

// Debug WordPress (temporaire)
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

// Augmenter la mémoire si vous êtes limite (utile lors d'opérations lourdes)
define('WP_MEMORY_LIMIT', '256M');

Sauvegarde avant réparation (WP-CLI)

Si WP-CLI fonctionne encore, faites un dump. Même si la base est “abîmée”, vous voulez un état figé pour analyse.

# Dump SQL (ajoutez --single-transaction si InnoDB majoritaire)
wp db export "backup-avant-repair-$(date +%F-%H%M).sql"

# Optionnel : compresser
gzip -9 "backup-avant-repair-$(date +%F-%H%M).sql"

Si WP-CLI ne fonctionne pas, passez par mysqldump (ou l’export phpMyAdmin), mais gardez en tête qu’une table corrompue peut interrompre le dump.

Solution 1 : Réparer les tables via WP-CLI (CHECK/REPAIR/OPTIMIZE)

C’est ma voie par défaut dès que j’ai SSH. Elle est scriptable, loggable, et reproductible. WP-CLI s’appuie sur les commandes SQL standard via les identifiants de wp-config.php.

Étape 1 — Identifier les tables et leur moteur

Commencez par voir ce qui est réellement cassé.

# Vérifier l'intégrité des tables (équivalent CHECK TABLE)
wp db check

Puis listez les tables et leurs engines. WP-CLI n’a pas une commande “engine” dédiée ; utilisez une requête SQL.

# Remplacez wp_ si votre préfixe est différent
wp db query "
SELECT TABLE_NAME, ENGINE, TABLE_ROWS, DATA_LENGTH, INDEX_LENGTH
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME LIKE 'wp_%'
ORDER BY (DATA_LENGTH + INDEX_LENGTH) DESC;
"

Décision :

Si les tables en erreur sont MyISAM : REPAIR TABLE a de bonnes chances d’aider.
Si l’erreur est InnoDB page corruption : ne vous attendez pas à un miracle avec wp db repair. Passez à la solution 3 (restauration) ou au dépannage serveur.

Étape 2 — Réparer (MyISAM principalement)

# Lance REPAIR TABLE sur les tables concernées
wp db repair

Dans WordPress, l’écran /wp-admin/maint/repair.php existe depuis longtemps, mais je préfère WP-CLI : moins d’exposition, moins de risques d’oublier de désactiver.

Source officielle (réparation DB) : developer.wordpress.org — Repairing the Database.

Étape 3 — Optimiser après réparation (optionnel, mais utile)

Après un REPAIR, vous avez souvent des index reconstruits mais une fragmentation. Sur MyISAM, OPTIMIZE TABLE peut réduire la taille et améliorer les scans. Sur InnoDB, l’effet varie (rebuild table selon config).

wp db optimize

Le “AVANT / APRÈS” côté code (erreur fréquente : réparer via le web en prod)

J’ai souvent vu des admins activer la réparation via WP_ALLOW_REPAIR et oublier de la retirer. C’est un anti-pattern : vous exposez un endpoint de maintenance.

AVANT (cassé : endpoint de réparation laissé actif)

<?php
// wp-config.php
define('WP_ALLOW_REPAIR', true); // Mauvaise idée si vous oubliez de le retirer

APRÈS (corrigé : réparation via WP-CLI, pas d’endpoint exposé)

# Réparer via WP-CLI puis retirer toute configuration temporaire
wp db check
wp db repair
wp db optimize

Pourquoi c’est mieux : vous évitez d’exposer une page de maintenance accessible sans authentification (selon configuration), et vous gardez une trace dans votre historique shell/CI.

Cas avancé — Réparer une table précise et comprendre l’erreur

Quand une seule table est en cause, ciblez-la. Exemple : wp_postmeta en MyISAM (ça arrive sur de vieux sites ou des migrations partielles).

wp db query "CHECK TABLE wp_postmeta;"
wp db query "REPAIR TABLE wp_postmeta;"
wp db query "ANALYZE TABLE wp_postmeta;"

Edge case : si la table est énorme, REPAIR peut prendre longtemps et bloquer (table lock). Sur un site à trafic, faites-le en fenêtre de maintenance, ou clonez et réparez hors prod.

Solution 2 : Réparer via phpMyAdmin (et savoir quand ça ne sert à rien)

phpMyAdmin est utile quand vous êtes en mutualisé sans SSH, ou quand WP-CLI ne peut plus se connecter. Mais il faut comprendre ce que vous faites : cliquer sur “Réparer la table” en InnoDB ne résout pas une corruption de pages InnoDB.

Étape 1 — Vérifier le moteur et l’état

Ouvrez phpMyAdmin → sélectionnez la base → onglet “Structure”.
Affichez la colonne Type (ENGINE). Si elle n’est pas visible, phpMyAdmin peut l’afficher via options.
Repérez les tables en erreur (souvent signalées).

Étape 2 — Opérations “Check / Repair / Optimize”

Pour des tables MyISAM :

Cochez les tables concernées.
Menu déroulant → Check table (diagnostic).
Puis Repair table.
Enfin Optimize table.

Pour des tables InnoDB :

Check table peut remonter des erreurs, mais “Repair table” est généralement inopérant (ou non supporté selon versions).
Si vous voyez “InnoDB: page corruption”, vous êtes dans un scénario de restauration/infra.

AVANT / APRÈS (erreur fréquente : exécuter une requête destructive “pour tester”)

Je vois encore des gens exécuter des requêtes “nettoyantes” trouvées sur un forum alors que la table est corrompue. Vous perdez des données et vous compliquez la récupération.

AVANT (cassé : suppression agressive sans sauvegarde)

# Ne faites pas ça en premier : vous masquez le problème et perdez des données
DELETE FROM wp_options WHERE option_name LIKE '%transient%';

APRÈS (corrigé : d’abord figer, diagnostiquer, puis réparer/restaurer)

# 1) Sauvegarde
wp db export backup-avant-action.sql

# 2) Diagnostic
wp db check

# 3) Réparation si MyISAM
wp db repair

Cas “phpMyAdmin ne s’ouvre plus”

Si phpMyAdmin renvoie une erreur de connexion ou timeouts :

Vérifiez l’espace disque (souvent la vraie cause).
Vérifiez que MySQL/MariaDB tourne réellement.
Regardez les logs (mutualisé : souvent via panel ; VPS : /var/log/mysql/error.log ou journald).

Solution 3 : Restaurer proprement (snapshot) et rejouer les deltas (uploads, options, commandes)

Quand InnoDB est corrompu, “réparer” au niveau SQL est rarement la bonne réponse. La stratégie fiable : restaurer un snapshot sain (ou un dump) puis rejouer ce qui a changé depuis (uploads, commandes WooCommerce, formulaires, etc.).

Scénario A — Vous avez un backup récent (recommandé)

Restaurez :

Base de données (dump SQL ou snapshot DB managé).
Fichiers wp-content/uploads (et éventuellement plugins si vous n’utilisez pas de déploiement).

Puis exécutez une vérification WordPress :

# Vérifier que WordPress “voit” la DB
wp core version
wp option get siteurl
wp option get home

# Vérifier l'intégrité
wp db check

Scénario B — Vous devez récupérer depuis une base corrompue

Si vous n’avez pas de backup exploitable, vous êtes en mode “forensic”. À ce stade, vos chances dépendent du moteur :

MyISAM : REPAIR TABLE + export partiel table par table.
InnoDB : vous pouvez parfois démarrer MySQL avec innodb_force_recovery (niveau 1 à 6) pour extraire les données, puis reconstruire une base propre. C’est une opération serveur, risquée : faites-la sur une copie, jamais sur l’instance prod.

Documentation MySQL (référence) : MySQL Manual — innodb_force_recovery.

Rejouer les deltas (exemples concrets)

Après restauration, vous devez souvent rejouer :

Uploads ajoutés depuis le backup (rsync depuis un snapshot fichiers).
Commandes (WooCommerce) : parfois impossibles à “rejouer” sans logs applicatifs → d’où l’importance d’un backup fréquent.
Options : si un builder (Divi 5, Elementor, Avada) a des réglages récents, exportez/importez leurs paramètres si disponibles.

Compatibilité page builders (Divi 5 / Elementor / Avada)

Elementor : après une restauration DB, régénérez CSS/data si l’éditeur affiche des styles manquants. Souvent, le problème n’est pas la DB mais des caches post-restauration. Vérifiez aussi les tables custom d’Elementor si elles existent sur votre version.
Divi 5 : si vous restaurez un snapshot, assurez-vous que les options de thème et la bibliothèque sont cohérentes. Les corruptions touchent souvent wp_options (autoload) et se voient immédiatement.
Avada : Avada/Fusion stocke beaucoup d’options. Après restauration, videz les caches (plugin cache, serveur, CDN) pour éviter un faux diagnostic.

Vérifications après correction

Une “réparation” n’est validée que si vous avez supprimé les symptômes et stabilisé la cause. Voici ma checklist.

1) Vérifier les tables

wp db check

2) Vérifier les erreurs WordPress

Contrôlez wp-content/debug.log si vous l’avez activé, puis désactivez le debug si tout est OK.

3) Vérifier les endpoints critiques

# REST API (doit renvoyer du JSON)
curl -sS https://example.com/wp-json/ | head

# Cron (si vous l’utilisez)
wp cron event run --due-now

4) Vérifier les requêtes lentes (Query Monitor)

Si le site “marche” mais rame, j’ouvre Query Monitor et je regarde :

Requêtes qui scannent wp_postmeta sans index.
Erreurs SQL silencieuses.
Temps total DB anormal.

5) Vérifier le serveur MySQL/MariaDB

Sur VPS, lisez les logs MySQL/MariaDB. Une réparation qui “tient” 30 minutes puis recasse pointe souvent vers une instabilité I/O.

Si ça ne marche toujours pas

Quand les commandes “réussissent” mais que le site reste instable, suivez cet ordre. Il évite de perdre du temps sur WordPress alors que le problème est en dessous.

1) Espace disque et inodes

Disque plein : MySQL peut corrompre/arrêter des écritures.
Inodes saturés : mêmes symptômes, surtout sur mutualisé.

2) Logs MySQL/MariaDB (la vérité est là)

Recherchez :

InnoDB: page corruption
InnoDB: Unable to read
Fatal error: ...
Redémarrages répétés de mysqld

3) Isoler thème/plugins (sans casser le site public)

Une corruption DB peut déclencher des erreurs, mais l’inverse existe aussi : un plugin qui tue MySQL via requêtes monstrueuses peut provoquer des crashs répétés.

Utilisez Health Check en mode dépannage.
Désactivez temporairement les plugins lourds (cache, sécurité, builders) pour tester la stabilité.

4) Cache (faux positifs)

Videz le cache plugin (WP Rocket, LiteSpeed Cache, etc.).
Videz le cache serveur (Varnish) et CDN.
Videz le cache navigateur quand vous testez wp-admin (j’ai déjà vu une admin “cassée” à cause d’un JS servi en cache alors que la DB était réparée).

5) Réécriture et permaliens

Ce n’est pas une corruption DB, mais après restauration/migration, des 404 peuvent vous induire en erreur.

wp rewrite flush --hard

6) Vérifier la version PHP

Si vous êtes encore sur PHP 7.4/8.0, vous cumulez les risques (incompatibilités plugins, erreurs fatales). WordPress 6.9.4 tourne très bien sur PHP 8.1/8.2. Référence PHP : php.net — Supported Versions.

Pièges et erreurs courantes

Symptôme / erreur	Cause probable	Solution recommandée
“Repair table” ne change rien	Tables InnoDB, corruption de pages / problème infra	Restaurer un backup, diagnostiquer MySQL (logs), envisager `innodb_force_recovery` sur copie
Vous avez “réparé” puis perdu des contenus	REPAIR MyISAM a supprimé des lignes irrécupérables	Revenir au dump/snapshot, extraire table par table, accepter une récupération partielle
Vous testez directement en production	Pas d’environnement de staging, pas de snapshot	Cloner (staging), réparer là-bas, puis basculer
Le site est OK mais l’admin reste cassée	Cache JS/CSS, builder qui sert des assets en cache	Vider caches (plugin/serveur/CDN), régénérer assets builder
Erreur “Access denied” WP-CLI	Mauvais `DB_USER`/`DB_PASSWORD`, ou droits SQL limités	Vérifier `wp-config.php`, accorder privilèges (SELECT/REPAIR/ALTER selon besoin)
Snippet “réparation” copié dans functions.php	Copier du code au mauvais endroit (et casser le site)	Ne mettez pas de logique DB en front. Utilisez WP-CLI / maintenance contrôlée
Erreur PHP après “réparation”	Vous avez activé WP_DEBUG et oublié de le désactiver, ou plugin incompatible PHP	Revenir à une config sûre, mettre à jour plugins/thème, PHP 8.1+

Erreur de débutant… chez des avancés : confondre action et filtre (et casser un mu-plugin)

Quand le site est en feu, je vois des mu-plugins ajoutés à la va-vite pour “désactiver” des choses, parfois avec un hook inadapté. Résultat : fatal error, impossible d’accéder à wp-admin, et on accuse la base.

AVANT (cassé : hook inadapté + syntaxe fragile)

<?php
// mu-plugin ajouté en urgence, mais cassé (point-virgule manquant)
add_filter('init', function () {
    remove_all_actions('wp_loaded')
})

APRÈS (corrigé : mu-plugin minimal, sûr, et réversible)

<?php
/**
 * Plugin Name: Urgence - Désactivation temporaire d'un plugin (exemple)
 * Description: Exemple de mu-plugin réversible, sans toucher à la base.
 */

// Commentaire : évitez de bricoler la base en production ; isolez d'abord le code.
add_action('plugins_loaded', function () {
    // Ici, vous pourriez conditionner des désactivations, logs, etc.
}, 1);

Variante / alternative

Méthode “sans code” : l’écran de réparation WordPress (à utiliser avec prudence)

WordPress a un mode réparation accessible via /wp-admin/maint/repair.php si vous activez WP_ALLOW_REPAIR. C’est utile en mutualisé sans SSH, mais je le considère comme une solution de dernier recours.

Doc officielle : wp-config — Repairing the Database.

<?php
// wp-config.php — temporairement
define('WP_ALLOW_REPAIR', true); // Commentaire : à retirer immédiatement après usage

Risques :

Vous oubliez de le retirer.
Vous faites une réparation sans logs ni contrôle fin.

Méthode plus avancée : conteneuriser WP-CLI + accès DB via bastion

Sur des stacks modernes, j’exécute WP-CLI dans un conteneur “tooling” (même réseau que DB), avec des credentials temporaires. Ça permet d’auditer et réparer sans ouvrir phpMyAdmin au monde.

Référence WP-CLI : developer.wordpress.org — WP-CLI db commands.

Éviter ce problème à l’avenir

La réparation est du curatif. Les vraies victoires sont en prévention : backups testés, InnoDB partout, monitoring, et une discipline de déploiement.

1) Standardiser InnoDB (quand c’est possible)

Si vous trouvez encore des tables MyISAM (souvent des plugins anciens), planifiez une conversion après audit. Testez sur staging : certaines tables fulltext/héritées peuvent avoir des contraintes.

# Exemple : convertir une table (à tester, et hors pic trafic)
wp db query "ALTER TABLE wp_postmeta ENGINE=InnoDB;"

Attention : une conversion peut être longue et bloquante selon la taille. Faites-le en maintenance.

2) Backups automatiques + test de restauration

Gardez au moins : quotidien (7j), hebdo (4-6 semaines), mensuel (3-6 mois).
Testez une restauration sur staging. Un backup non testé n’est pas un backup.

3) Monitoring MySQL et alertes disque

Alerte à 80% disque, puis 90% critique.
Surveillez les redémarrages mysqld et les erreurs InnoDB.

4) Limiter les “gros autoload” (wp_options)

Sur des sites avec Divi/Elementor/Avada et beaucoup d’extensions, wp_options gonfle vite. Ça ne “corrompt” pas, mais ça amplifie l’impact d’un souci (timeouts, crashs). Après stabilisation, auditez l’autoload.

# Mesurer le poids de l'autoload
wp db query "
SELECT ROUND(SUM(LENGTH(option_value))/1024/1024, 2) AS autoload_mb
FROM wp_options
WHERE autoload='yes';
"

5) Sécurité : évitez d’exposer des outils DB

phpMyAdmin derrière VPN/bastion si possible.
Comptes DB à privilèges minimaux pour WordPress (évitez GRANT ALL en prod).

Ressources

Questions fréquentes

Est-ce que `wp db repair` marche pour InnoDB ?

Ça dépend de ce que vous appelez “corruption”. Pour des incohérences mineures ou des index, vous pouvez voir une amélioration. Pour une corruption de pages InnoDB (logs MySQL explicites), non : la stratégie fiable est la restauration ou une récupération InnoDB côté serveur sur copie.

Dois-je activer `WP_ALLOW_REPAIR` sur un site en production ?

Uniquement si vous n’avez pas SSH et que vous êtes bloqué. Activez-le temporairement, exécutez l’opération, puis retirez-le immédiatement. Je préfère WP-CLI pour éviter d’exposer une surface d’attaque inutile.

Pourquoi la corruption revient après une réparation réussie ?

Parce que la cause racine est toujours là : disque saturé, erreurs I/O, mysqld tué par l’OOM killer, conteneur instable, ou stockage réseau. Une réparation MyISAM peut “tenir” jusqu’au prochain incident.

Quelle est la première chose à faire si je vois “marked as crashed” ?

Sauvegarde (même partielle), puis identifiez le moteur. Si c’est MyISAM : wp db repair est un bon premier geste. Si c’est InnoDB : cherchez plutôt dans les logs MySQL.

Est-ce que phpMyAdmin est fiable pour réparer ?

Pour MyISAM, oui, c’est souvent équivalent à exécuter REPAIR TABLE. Pour InnoDB, phpMyAdmin ne résoudra pas une corruption de pages. Il reste utile pour diagnostiquer et exporter ce qui est exportable.

Est-ce que Divi/Elementor/Avada peuvent corrompre la base ?

Ils peuvent amplifier la charge (beaucoup d’options, de postmeta, d’Ajax), ce qui peut exposer une faiblesse serveur. Mais une “corruption” est quasi toujours liée à l’arrêt brutal de MySQL, au stockage ou à une restauration/migration ratée.

Que faire si `wp db export` échoue à cause d’une table corrompue ?

Essayez d’exporter table par table (ou d’ignorer la table fautive via mysqldump), puis récupérez ce que vous pouvez. Sur InnoDB, envisagez une récupération côté serveur sur une copie (force recovery) pour extraire un maximum.

Faut-il “optimiser” après réparation ?

Souvent oui, surtout sur MyISAM. Sur InnoDB, l’optimisation peut être plus coûteuse et moins bénéfique. Je le fais après stabilisation, pas pendant l’incident, et toujours avec une fenêtre de maintenance si les tables sont grosses.

Comment être sûr que ce n’est pas juste un problème de cache ?

Si vous voyez des erreurs SQL dans les logs (WordPress ou MySQL), ce n’est pas “juste” le cache. Mais après correction, un cache agressif peut faire croire que le bug est toujours là. Videz plugin/serveur/CDN, puis re-testez wp-admin et REST.