REPAIR TABLE tbl_name[,tbl_name...] [QUICK] [EXTENDED] [USE_FRM]

REPAIR TABLE répare une table possiblement corrompue. Par défaut, elle a le même effet que myisamchk --recover tbl_name sur une table. REPAIR TABLE fonctionne unqiuement avec les tables MyISAM.

Normalement, vous n'avez pas à exécuter cette commande, mais si une catastrophe vous frappe, vous êtes presque assurés de retrouver vos données dans les tables MyISAM, avec la commande REPAIR TABLE. Si vos tables sont souvent corrompues, vous devrie toutefois rechercher la cause de ce problème! See Section A.4.2, « Que faire si MySQL plante constamment ? ». See Section 14.1.4, « Problèmes avec les tables MyISAM ».

REPAIR TABLE répare autant que possible les tables corrompues. La commande retourne la table suivante :

La commande REPAIR TABLE pourrait afficher plusieurs messages pour chaque table. La dernière ligne doit être du format Msg_type status et doit être normalement OK. Si vous n'obtenez pas OK, vous devez essayer de réparer votre table avec la commande myisamchk -o, car REPAIR TABLE de supporte pas encore toutes les options de myisamchk. Dans un futur proche, nous allons rendre cette commande encore plus souple.

Si l'option QUICK est fournie, alors MySQL va essayer de ne réparer que le fichier d'index. Ce type de réparation est le même que myisamchk --recover --quick.

Si vous utilisez l'option EXTENDED, alors MySQL va essayer de créer l'index ligne par ligne, au lieu de créer un index à la fois, par tri. C'est une méthode qui peut s'avérer plus efficace que de trier sur des clés de taille fixe, si vous avez des clés CHAR longues qui se compressent bien. Ce type de réparation est l'équivalent de myisamchk --safe-recover.

Depuis MySQL 4.0.2, il existe le mode USE_FRM pour REPAIR. Utilisez-le si le fichier .MYI manque, ou si son entête est corrompu. Avec ce mode, MySQL va recréer le fichier .MYI, en utilisant les informations du fichier .frm. Ce type de réparation ne peut pas être fait avec myisamchk.

Attention : si le serveur s'arrête durant l'opération REPAIR TABLE, il est important d'exécuter à nouveau la commande REPAIR TABLE après le redémarrage (il est bon de faire une sauvegarde de toutes manières). Dans le pire scénario, vous pourriez vous retrouver avec un nouvel index sans relation avec les données, et la prochaine opération risque d'écraser le fichier de données. C'est peu probable, mais possible.

Avant MySQL 4.1.1, les commandes REPAIR TABLE n'étaient pas écrites dans le log binaire. Depuis MySQL 4.1.1, elles sont écrites dans le log binaire à moins que la clause NO_WRITE_TO_BINLOG ne soit utilisée (aussi connue sous le nom de LOCAL).