MySQL dispone de diferentes comandos para comprobar, reparar y optimizar tablas, pero no todos sirven para lo mismo ni funcionan con todos los motores de almacenamiento.
Antes de ejecutar cualquier operación conviene identificar el problema y comprobar si las tablas utilizan InnoDB, MyISAM u otro motor.
Este punto es especialmente importante porque InnoDB es actualmente el motor predeterminado de MySQL y REPAIR TABLE, uno de los comandos que aparece habitualmente en tutoriales antiguos, no permite reparar tablas InnoDB.
Antes de reparar una base de datos, haz una copia de seguridad
Cualquier operación destinada a reparar o reconstruir tablas debe realizarse con precaución.
Si los datos son importantes, el primer paso debería ser disponer de una copia de seguridad recuperable.
No conviene utilizar comandos de reparación como prueba y error sobre una base de datos de producción sin saber previamente qué está ocurriendo.
La propia documentación de MySQL recomienda realizar una copia antes de operaciones de reparación, ya que determinadas situaciones de corrupción pueden implicar pérdida de datos.
Cómo saber qué motor utiliza una tabla
Antes de intentar repararla podemos consultar su motor con:
SHOW TABLE STATUS;
Si queremos comprobar una tabla concreta:
SHOW TABLE STATUS LIKE 'nombre_tabla';
Otra posibilidad es utilizar:
SHOW CREATE TABLE nombre_tabla;
En el resultado podremos comprobar si aparece, por ejemplo:
ENGINE=InnoDB
o:
ENGINE=MyISAM
Esta información determinará qué operaciones podemos utilizar.
Comprobar una tabla con CHECK TABLE
Si sospechamos que existe un problema, lo razonable es comprobar primero la tabla, no intentar repararla directamente.
Podemos utilizar:
CHECK TABLE nombre_tabla;
MySQL devolverá información sobre el estado de la tabla y, en condiciones normales, finalizará con un estado OK.
CHECK TABLE puede utilizarse con motores como InnoDB y MyISAM, aunque su funcionamiento interno depende del motor de almacenamiento.
También podemos comprobar varias tablas en una misma operación:
CHECK TABLE tabla1, tabla2, tabla3;
Si el resultado no indica ningún error, no existe motivo para ejecutar una reparación simplemente como tarea preventiva.
Reparar una tabla MySQL con REPAIR TABLE
Cuando una tabla MyISAM aparece realmente dañada, podemos utilizar:
REPAIR TABLE nombre_tabla;
También existen opciones como QUICK o EXTENDED para determinados escenarios de reparación.
Sin embargo, aquí está una de las diferencias más importantes respecto a muchos tutoriales antiguos:
REPAIR TABLE no funciona con tablas InnoDB.
MySQL limita esta instrucción a determinados motores, entre ellos MyISAM, ARCHIVE y CSV.
Por tanto, si tenemos:
ENGINE=InnoDB
no debemos intentar solucionar una corrupción simplemente ejecutando REPAIR TABLE.
Una corrupción real de InnoDB requiere diagnosticar el problema, revisar los logs de MySQL y plantear la recuperación de acuerdo con la situación concreta.
¿Para qué sirve OPTIMIZE TABLE?
OPTIMIZE TABLE tiene una finalidad diferente.
Podemos ejecutarlo mediante:
OPTIMIZE TABLE nombre_tabla;
Su objetivo es reorganizar el almacenamiento físico de los datos y los índices. Dependiendo del motor y de la situación puede ayudar a recuperar espacio no utilizado y mejorar la organización interna de la tabla.
Por ejemplo, puede tener sentido después de haber eliminado o modificado una cantidad muy grande de registros.
En tablas InnoDB, OPTIMIZE TABLE puede provocar una reconstrucción de la tabla. Esto significa que no debería considerarse una operación gratuita ni ejecutarse indiscriminadamente sobre bases de datos grandes en producción.
¿Hay que optimizar periódicamente todas las tablas?
No necesariamente.
Uno de los errores habituales consiste en ejecutar OPTIMIZE TABLE sobre toda la base de datos de forma periódica simplemente porque parece una tarea de mantenimiento recomendable.
En una base de datos moderna no deberíamos hacerlo sin una razón.
Si una tabla funciona correctamente y no ha sufrido cambios que justifiquen una reorganización, optimizarla repetidamente puede aportar poco o nada y, en cambio, consumir recursos durante el proceso.
La optimización debe responder a un problema o necesidad concreta, por ejemplo una gran cantidad de espacio liberado después de eliminaciones masivas.
Tampoco debemos confundir OPTIMIZE TABLE con la optimización del rendimiento de las consultas.
Una consulta lenta puede deberse a índices incorrectos, una consulta SQL mal diseñada, estadísticas, configuración del servidor o problemas de recursos. En esos casos reconstruir la tabla no resolverá necesariamente el problema.
ANALYZE TABLE tampoco es lo mismo que OPTIMIZE
Existe otra instrucción relacionada con el mantenimiento:
ANALYZE TABLE nombre_tabla;
ANALYZE TABLE actualiza estadísticas que utiliza el optimizador de MySQL para decidir cómo ejecutar las consultas.
En InnoDB, por ejemplo, analiza la distribución de los índices y actualiza las estimaciones de cardinalidad.
Por tanto:
CHECK TABLE comprueba posibles errores.
REPAIR TABLE intenta reparar determinados motores compatibles.
OPTIMIZE TABLE reorganiza el almacenamiento de la tabla.
ANALYZE TABLE actualiza información estadística utilizada por el optimizador.
Son operaciones diferentes y no deberían ejecutarse como si fueran equivalentes.
Reparar y optimizar desde phpMyAdmin
phpMyAdmin también permite realizar algunas de estas operaciones desde su interfaz.
Normalmente podemos seleccionar una o varias tablas dentro de la base de datos y utilizar las opciones de mantenimiento disponibles para comprobarlas u optimizarlas.
La ventaja es que no necesitamos escribir directamente las sentencias SQL.
Sin embargo, utilizar phpMyAdmin no cambia el funcionamiento de MySQL: las mismas limitaciones del motor de almacenamiento siguen existiendo.
Si una tabla InnoDB no admite REPAIR TABLE, hacerlo desde una interfaz gráfica no elimina esa limitación.
¿Qué hacer si una base de datos sigue dando errores?
Si las tablas muestran errores recurrentes, repararlas una y otra vez no debería convertirse en la solución.
Conviene investigar la causa.
Un servidor que se apaga inesperadamente, problemas de almacenamiento, falta de espacio, errores de hardware o fallos del propio servicio pueden provocar incidencias que volverán a aparecer aunque consigamos recuperar temporalmente una tabla.
La documentación de MySQL recomienda investigar especialmente las corrupciones repetidas de MyISAM y comprobar si coinciden con reinicios inesperados del servidor.
En sistemas críticos, la prioridad debe ser identificar el origen del problema y disponer de una estrategia de backup y recuperación adecuada.
Comprobar antes de reparar
Las herramientas de mantenimiento de MySQL siguen siendo útiles, pero deben utilizarse con criterio.
Primero debemos identificar el motor de almacenamiento y comprobar el estado de la tabla. Solo después tiene sentido decidir si debemos reparar, optimizar, analizar o aplicar otro procedimiento.
Especialmente con InnoDB, no debemos asumir que una base de datos con problemas se soluciona ejecutando automáticamente REPAIR TABLE u OPTIMIZE TABLE.
La operación correcta depende del problema que estemos intentando resolver.