Qué importa primero: WordPress llegó a la base de datos, pero una tabla no se puede leer normalmente. Los pasos de reparación difieren para MyISAM y InnoDB, y una reparación visible puede fallar si se mantiene la presión del disco o del hardware.
Qué indica realmente este síntoma
Esto no es lo mismo que credenciales de base de datos inválidas. El nombre de la tabla, el motor, el servidor log y el estado del disco determinan si una reparación a nivel de tabla es apropiada o una restauración es más segura.
Recopila pruebas antes de cambiar nada
- Graba la tabla exacta y el error SQL.
- Crear un volcado de base de datos o instantánea de almacenamiento antes de los intentos de reparación.
- Comprueba el motor de la tabla, espacio libre en disco y error de base de datos log.
- Determinar si otras tablas o bases de datos muestran corrupción.
Causas más habituales
- Un apagado sucio: Un choque o reinicio forzado dejó una tabla no transaccional inconsistente.
- Problema de disco o sistema de archivos: El disco completo, los errores de E/S o el almacenamiento fallido interrumpe las escrituras.
- Daño al índice MyISAM: Las tablas de legado a menudo se pueden comprobar y reparar a nivel de tabla.
- Corrupción de InnoDB: El daño de la tabla transaccional puede requerir modo de recuperación o restauración, no REPAIR TABLE.
Secuencia segura de diagnóstico y reparación
- Estabilizar el espacio en disco y el servicio de base de datos antes de modificar la tabla.
- Usa la TABLA DE VERIFICACIÓN para confirmar el alcance y la orientación específica del motor.
- Reparar solo los motores compatibles, o restaurar la tabla afectada de una copia de seguridad verificada.
- Ejecutar controles a nivel de aplicación después de la recuperación porque el éxito estructural no prueba la integridad de los datos.
Cómo distinguir entre las causas probables
No trates Un apagado sucio y Problema de disco o sistema de archivos como causas equivalentes. Un choque o reinicio forzado dejó una tabla no transaccional inconsistente. En cambio, el disco completo, los errores de E/S o el almacenamiento fallido interrumpe las escrituras. Para distinguirlas, usa estas dos comprobaciones: Graba la tabla exacta y el error SQL; y crear un volcado de base de datos o instantánea de almacenamiento antes de los intentos de reparación. Con esos datos podrás decidir si conviene aplicar la primera acción controlada —Estabilizar el espacio en disco y el servicio de base de datos antes de modificar la tabla— o si debes conservar el estado actual y ampliar la investigación.
En un sitio de WordPress en producción, repite la petición que falla mientras compruebas una página que funciona correctamente y el área de administración. Un fallo aislado en una ruta requiere un rollback más acotado que un problema que afecta a PHP, la base de datos o todas las peticiones. Documenta la fecha y hora exactas, la URL o transacción afectada, el último estado correcto conocido y cada cambio realizado durante el diagnóstico. Ese registro permite distinguir una reparación reproducible de una desaparición temporal del síntoma.
Qué no debes hacer
No active valores agresivos de recuperación de fuerza InnoDB y continúe con las escrituras normales. El modo de recuperación es para extraer datos en condiciones controladas.
Cómo verificar la reparación
- La tabla afectada pasa los controles estructurales.
- WordPress lee y escribe correctamente la característica relacionada.
- Base de datos y sistema logs no muestran errores de E/S o corrupción continuos.
Que el síntoma visible desaparezca no es suficiente. Cierra la incidencia solo cuando la acción original que fallaba, el recorrido de negocio relacionado y los registros relevantes confirmen que el problema ha desaparecido.