Una tabla corrupta es casi siempre un síntoma: un corte de luz, un disco que se llenó, o hardware que se está muriendo. Repare la tabla y luego averigüe cuál de las tres fue; si no, volverá a pasar la semana que viene.

MyISAM

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

MyISAM no tiene recuperación tras caída, así que un apagado sucio deja las tablas marcadas como caídas. REPAIR suele arreglarlas en segundos, y puede tirar las filas dañadas.

InnoDB es otra cosa

REPAIR TABLE no funciona en InnoDB, y la corrupción allí es seria: normalmente el motor se recupera solo al arrancar. Si InnoDB informa de corrupción, el camino seguro es restaurar desde una copia, no intentar una reparación.
mysql -e "CHECK TABLE shop.orders"
sudo tail -100 /var/log/mysql/error.log

Si el servidor no arranca por eso

# my.cnf - TEMPORARY, to get the data out
innodb_force_recovery = 1
  1. Empiece en 1 y suba solo si no arranca — los niveles por encima de 4 pueden destruir datos.
  2. Vuelque todo en cuanto arranque — mysqldump --all-databases > rescue.sql
  3. Quite el ajuste y reconstruya el directorio de datos — e importe el volcado.
Por encima de innodb_force_recovery = 3 el motor corre en un modo degradado donde las escrituras pueden empeorar las cosas. Saque el volcado y salga; no monte un sitio encima de eso.

Luego encuentre la causa

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

Y salga de MyISAM

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

ALTER TABLE shop.sessions ENGINE=InnoDB;
InnoDB tiene recuperación tras caída, bloqueo por fila y transacciones de verdad. No hay ninguna buena razón para que una tabla nueva sea MyISAM, y convertir elimina toda esta familia de problemas.