Une table corrompue est presque toujours un symptôme : une coupure de courant, un disque qui s'est rempli, ou du matériel qui lâche. Réparez la table, puis découvrez lequel des trois c'était - sinon cela recommencera la semaine prochaine.

MyISAM

mysqlcheck --check --auto-repair --databases shop
# or, for one table
mysql -e "REPAIR TABLE shop.sessions"

MyISAM n'a pas de reprise après incident : un arrêt brutal laisse donc les tables marquées comme plantées. REPAIR les remet d'ordinaire d'aplomb en quelques secondes, et peut jeter les lignes abîmées.

InnoDB, c'est autre chose

REPAIR TABLE ne marche pas sur InnoDB, et une corruption y est grave : normalement le moteur se remet seul au démarrage. Si InnoDB signale une corruption, la voie sûre est la restauration depuis une sauvegarde, pas une tentative de réparation.
mysql -e "CHECK TABLE shop.orders"
sudo tail -100 /var/log/mysql/error.log

Si le serveur refuse de démarrer à cause de cela

# my.cnf - TEMPORARY, to get the data out
innodb_force_recovery = 1
  1. Commencez à 1 et n'augmentez que s'il ne démarre pas — au-delà du niveau 4, on peut détruire des données.
  2. Exportez tout dès qu'il démarre — mysqldump --all-databases > rescue.sql
  3. Retirez le réglage, reconstruisez le répertoire de données — puis importez l'export.
Au-dessus de innodb_force_recovery = 3, le moteur tourne en mode dégradé où les écritures peuvent aggraver les choses. Récupérez l'export et sortez ; ne faites pas tourner un site là-dessus.

Puis trouvez la cause

sudo dmesg -T | grep -iE 'i/o error|ata|nvme'
df -h
sudo smartctl -H /dev/sda

Et quittez MyISAM

SELECT table_name, engine FROM information_schema.tables
 WHERE table_schema = 'shop' AND engine <> 'InnoDB';

ALTER TABLE shop.sessions ENGINE=InnoDB;
InnoDB a la reprise après incident, le verrouillage par ligne et de vraies transactions. Il n'y a aucune bonne raison pour qu'une table neuve soit en MyISAM, et convertir supprime toute cette famille de problèmes.