REPAIR TABLE
REPAIR [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name[,tbl_name...] [QUICK] [EXTENDED] [USE_FRM]
REPAIR TABLE funciona sólo con tablas MyISAM y es lo mismo que ejecutar myisamchk -r table_name en la tabla.
Normalmente nunca se tendrá que ejecutar este comando, pero si ocurre un desastre es muy probable que se puedan recuperar todos los datos de una tabla MyISAM con REPAIR TABLE. Si las tablas están muy corruptas, se debe intentar encontrar el motivo, para eliminar la necesidad de usar REPAIR TABLE.
REPAIR TABLE repara una tabla posiblemente corrupta. El comando devuelve una tabla con las columnas siguientes:
| Columna | Valor |
|---|---|
| Table | Nombre de tabla |
| Op | Siempre "repair" (reparar) |
| Msg_type | Uno de "status", "error", "info" o "warning" (estado, error, información o aviso) |
| Msg_text | El mensaje |
La sentencia puede producir muchas filas de información para cada tabla reparada. La última fila será de estado y debe ser normalemente OK. Si no se obtiene un OK, se debe intentar reparar la tabla con myisamchk --safe-recover, ya que REPAIR TABLE aún no tiene implementadas todas las opciones de myisamchk. En un futuro cercano, será más flexible.
Si se usa QUICK, REPAIR TABLE intenta reparar sólo el árbol de índices.
Si se usa EXTENDED, MySQL creará el índice fila a fila en lugar de crear un índice de una vez mediante ordenamiento; esto puede ser mejor que ordenar en claves de longitud constante si se tienen claves CHAR largas que se comprimen bien. Este tipo de reparación se como si se usase myisamchk --safe-recover.
Desde MySQL 4.0.2, existe un modo USE_FRM para REPAIR. Hay que usarlo si el fichero '.MYI' se ha perdido o si su cabecera está corrupta. En este modo MySQL recreará la tabla, usando información del fichero '.frm'. Este tipo de reparación no se puede hacer con myisamchk.
Cuidado: si mysqld muere durante un REPAIR TABLE, es esencial que lo primero que se haga sea otro REPAIR en la tabla antes de ejecutar cualquier otro comando en ella. (Por supuesto, es siempre mejor arrancar con un backup). En el peor caso se puede obtener un fichero de índices limpio sin información sobre el fichero de datos y con el siguiente comando se sobrescribe el fichero de datos. No es probable, pero es posible.
Antes de MySQL 4.1.1, los comandos REPAIR no actualizaban el diario binario. Desde MySQL 4.1.1 sí se hace, salvo que se use la palabra opcional NO_WRITE_TO_BINLOG (o su alias LOCAL).