Syntaxe de OPTIMIZE TABLE <<< |
Syntaxe de REPAIR TABLE | Syntaxe de RESTORE TABLE >>> |
14.5.2 Commandes d'entretien des tables 14.5 Référence de langage d'administration de la base de données 14 Syntaxe des commandes SQL Manuel de Référence MySQL 4.1 : Version Française . Syntaxe de ANALYZE TABLE . Syntaxe de BACKUP TABLE . Syntaxe de CHECK TABLE . Syntaxe de CHECKSUM TABLE . Syntaxe de OPTIMIZE TABLE ->Syntaxe de REPAIR TABLE . Syntaxe de RESTORE TABLE |
14.5.2.6 Syntaxe de REPAIR TABLE
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 ). |
<< | Syntaxe de REPAIR TABLE | >> |
Syntaxe de OPTIMIZE TABLE | Commandes d'entretien des tables | Syntaxe de RESTORE TABLE |