WordPress puede cargar con normalidad mientras falla una pantalla de plugin, el buscador, los comentarios o una tarea programada porque solo está dañada su tabla. Un error MySQL como «table is marked as crashed» es una prueba más sólida que el mensaje genérico de un plugin.
No ejecutes inmediatamente una reparación sobre todas las tablas. Conserva una copia e identifica tabla, motor y fallo exactos.
Guarda el error de base de datos
Relaciona la hora de la función fallida con los registros de PHP y MySQL. Anota base, tabla, código de error y patrón de consulta sin sus valores.
Pruebas útiles:
nombre de tabla y prefijo
motor de almacenamiento
resultado de CHECK TABLE
última hora conocida en funcionamiento
eventos de disco o servidor
plugin o función propietariaOculta contenidos y datos de clientes.
Haz una copia antes de reparar
Crea un volcado si MySQL aún puede leer la tabla y conserva el snapshot del hosting cuando exista. Un volcado lógico puede saltarse la tabla dañada: lee su salida y registro de errores.
No sobrescribas la última copia anterior a la corrupción con otra incompleta. Registra hora e instrucciones de restauración.
Si el disco está lleno, utiliza almacenamiento externo o libera espacio de forma controlada antes de generar archivos temporales grandes.
Identifica el motor de almacenamiento
MyISAM permite operaciones de reparación que no sirven para InnoDB. La corrupción de InnoDB puede exigir recuperación en el servidor y restauración en vez de un simple REPAIR TABLE.
Comienza con inspección de solo lectura:
SHOW TABLE STATUS LIKE 'wp_example';
CHECK TABLE wp_example;Sustituye explícitamente prefijo y tabla. Usa una cuenta autorizada y no ejecutes órdenes incompatibles con el motor.
Determina la importancia de los datos
Relaciona la tabla con el núcleo o el plugin que la creó. Averigua si contiene caché o registros reconstruibles, o datos autoritativos como contenido, pedidos, envíos o ajustes.
No elimines una tabla porque el plugin pueda «recrear» su esquema hasta saber si las filas son sustituibles.
Consulta la documentación del proveedor sobre reparación y migración.
Repara MyISAM con cautela
Para una tabla MyISAM confirmada como caída, utiliza la reparación compatible de cPanel, Plesk, phpMyAdmin o el alojamiento después de hacer copia. Mantén la web en modo de solo lectura o mantenimiento si todavía puede recibir escrituras.
Observa la salida y compara recuentos. Un mensaje correcto del motor no demuestra que cada registro lógico esté intacto.
No ejecutes optimización, importación o copia simultáneamente.
Trata InnoDB mediante el proveedor
Revisa el registro MySQL en busca de páginas, checksums, tablespaces y recuperación tras caída. Entrega al hosting gestionado o administrador las pruebas exactas.
Los modos de emergencia innodb_force_recovery sirven para extraer datos y pueden impedir escrituras; exigen conocimiento del servidor y un plan de restauración.
No copies archivos individuales de tablas InnoDB entre servidores sin metadatos y procedimiento compatibles.
Encuentra la causa original
El daño puede seguir a un disco lleno, apagado forzado, fallo de almacenamiento o caída del servidor. Reparar filas sin corregir la infraestructura favorece la recaída.
Comprueba disco, inodos, sistema de archivos e historial de apagados de MySQL. Actualiza el plugin responsable si realizó cambios de esquema inválidos.
Programa el mantenimiento fuera del tráfico y evita que se solapen copias e importaciones.
Valida la coherencia lógica
El motor puede hacer legible la tabla y dejar relaciones incompletas. En tablas del núcleo, compara entradas, metadatos, términos o comentarios; en una tabla de plugin, usa su herramienta de conciliación.
Comprueba identificadores y fechas recientes contra una copia y los registros. No inventes referencias ni renumeres filas. Si faltan datos, documenta la pérdida acotada y restaura únicamente el conjunto afectado mediante un proceso probado.
Verifica función y datos
Prueba lectura y escritura de la función exacta, además de acceso, editor y tareas programadas. Compara recuentos y registros recientes con copias o fuentes externas.
Vigila errores MySQL durante varios ciclos de escritura. El mantenimiento recurrente debe comprobar disco y copias; una tabla solo vuelve a ser fiable cuando funciona la aplicación y se entiende qué condición la dañó.