MySQL: # 126 - Fichier de clé incorrect pour la table

J'ai eu l'erreur suivante à partir d'une requête MySQL.

#126 - Incorrect key file for table

Je n'ai même pas déclaré de clé pour cette table, mais j'ai des indices. Quelqu'un sait-il quel pourrait être le problème?

Chaque fois que cela s'est produit, cela a été un disque complet d'après mon expérience.

ÉDITER

Il est également intéressant de noter que cela peut être causé par un disque virtuel complet lors de tâches telles que la modification d'une grande table si vous avez configuré un disque virtuel. Vous pouvez temporairement commenter la ligne du disque virtuel pour autoriser de telles opérations si vous ne pouvez pas en augmenter la taille.

Tout d'abord, vous devez savoir que les clés et les index sont des synonymes dans MySQL. Si vous regardez la documentation sur la syntaxe CREATE TABLE , vous pouvez lire:

KEYest normalement synonyme de INDEX. L'attribut key PRIMARY KEYpeut également être spécifié comme KEYétant donné dans une définition de colonne. Cela a été mis en œuvre pour la compatibilité avec d'autres systèmes de base de données.

Maintenant, le type d'erreur que vous obtenez peut être dû à deux choses:

• Problèmes de disque sur le serveur MySQL
• Clés / tables corrompues

Dans le premier cas, vous verrez que l'ajout d'une limite à votre requête peut résoudre temporairement le problème. Si cela le fait pour vous, vous avez probablement un tmpdossier trop petit pour la taille des requêtes que vous essayez de faire. Vous pouvez alors décider ou tmpagrandir, ou réduire vos requêtes! ;)

Parfois, tmpc'est assez grand mais toujours plein, vous devrez effectuer un nettoyage manuel dans ces situations.

Dans le second cas, il y a de réels problèmes avec les données de MySQL. Si vous pouvez réinsérer facilement les données, je vous conseillerais de simplement supprimer / recréer la table et de réinsérer les données. Si vous ne pouvez pas, vous pouvez essayer de réparer la table en place avec REPAIR table . C'est un processus généralement long qui pourrait très bien échouer.

Regardez le message d'erreur complet que vous obtenez:

Fichier de clé incorrect pour la table 'FILEPATH.MYI'; essayez de le réparer

Il mentionne dans le message que vous pouvez essayer de le réparer. De plus, si vous regardez le FILEPATH réel que vous obtenez, vous pouvez en savoir plus:

• si c'est quelque chose comme /tmp/#sql_ab34_23fça, cela signifie que MySQL doit créer une table temporaire en raison de la taille de la requête. Il le stocke dans / tmp, et qu'il n'y a pas assez d'espace dans votre / tmp pour cette table temporaire.

• s'il contient le nom d'une table réelle à la place, cela signifie que cette table est très probablement corrompue et que vous devez la réparer.

Si vous identifiez que votre problème est de la taille de / tmp, lisez simplement cette réponse à une question similaire pour le correctif: MySQL, Erreur 126: fichier de clé incorrect pour la table .

Suivre ces instructions m'a permis de recréer mon répertoire tmp et de résoudre le problème:

Affichez tous les systèmes de fichiers et leur utilisation du disque sous une forme lisible par l'homme:

df -h

Recherchez les processus dans lesquels des fichiers sont ouverts /tmp

sudo lsof /tmp/**/*

Puis démontez /tmpet /var/tmp:

umount -l /tmp
umount -l /var/tmp

Ensuite, supprimez le fichier de partition corrompu:

rm -fv /usr/tmpDSK

Ensuite, créez-en un nouveau:

/scripts/securetmp

Notez qu'en éditant le script Perl securetmp, vous pouvez définir manuellement la taille du répertoire tmp vous-même, mais le simple fait d'exécuter le script a augmenté la taille du répertoire tmp sur notre serveur d'environ 450 Mo à 4,0 Go.

L'erreur n ° 126 se produit généralement lorsque vous avez une table corrompue. La meilleure façon de résoudre ce problème est d'effectuer une réparation. Cet article peut vous aider:

http://dev.mysql.com/doc/refman/5.0/en/repair-table.html

J'ai eu cette erreur quand je mets ft_min_word_len = 2en my.cnf, ce qui réduit la longueur de mot minimum dans un index de texte intégral à 2, la valeur par défaut de 4.

La réparation de la table a résolu le problème.

Essayez d'utiliser la limite dans votre requête. C'est à cause du disque plein comme dit @Monsters X.

J'ai également fait face à ce problème et résolu par limite dans la requête, car les milliers d'enregistrements étaient là. Fonctionne maintenant bien :)

Je sais que c'est un vieux sujet mais aucune des solutions mentionnées n'a fonctionné pour moi. J'ai fait autre chose qui a fonctionné:

Tu dois:

1. arrêtez le service MySQL:
2. Ouvrez mysql \ data
3. Supprimez à la fois ib_logfile0 et ib_logfile1.
4. Redémarrez le service

repair table myschema.mytable;

J'ai résolu ce problème avec:

ALTER TABLE table ENGINE MyISAM;
ALTER IGNORE TABLE table ADD UNIQUE INDEX dupidx (field);
ALTER TABLE table ENGINE InnoDB;

Peut aider

• Réfs: MySQL: ALTER IGNORE TABLE donne "Violation de contrainte d'intégrité"

Aller à /etc/my.cnfet commentertmpfs

#tmpdir=/var/tmpfs

Cela résout le problème.

J'ai exécuté la commande suggérée dans une autre réponse et bien que le répertoire soit petit, il était vide, donc l'espace n'était pas le problème.

/var/tmp$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/vzfs              60G   51G  9.5G  85% /
none                  1.5G  4.0K  1.5G   1% /dev
tmpfs                 200M     0  200M   0% /var/tmpfs
/var/tmpfs$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/vzfs              60G   51G  9.5G  85% /
none                  1.5G  4.0K  1.5G   1% /dev
tmpfs                 200M     0  200M   0% /var/tmpfs

Essayez d'exécuter une commande de réparation pour chacune des tables impliquées dans la requête.

Utilisez l'administrateur MySQL, allez dans Catalogue -> Sélectionnez votre catalogue -> Sélectionnez une table -> Cliquez sur le bouton Maintenance -> Réparer -> Utiliser FRM.

Maintenant, les autres réponses l'ont résolu pour moi. Il s'avère que renommer une colonne et un index dans la même requête a provoqué l'erreur.

Ca ne fonctionne pas:

-- rename column and rename index
ALTER TABLE `client_types`
    CHANGE `template_path` `path` VARCHAR( 255 ) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
    DROP INDEX client_types_template_path_unique,
    ADD UNIQUE INDEX `client_types_path_unique` (`path` ASC);

Travaux (2 déclarations):

-- rename column
ALTER TABLE `client_types`
    CHANGE `template_path` `path` VARCHAR( 255 ) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL;
-- rename index
ALTER TABLE `client_types`
    DROP INDEX client_types_template_path_unique,
    ADD UNIQUE INDEX `client_types_path_unique` (`path` ASC);

C'était sur MariaDB 10.0.20. Il n'y avait aucune erreur avec la même requête sur MySQL 5.5.48.

mysql> set global sql_slave_skip_counter=1; start slave; show slave status\G

Ensuite, une erreur existe:

 Error 'Table './openx/f_scraper_banner_details' is marked as crashed and should be repaired' on query. Default database: 'openx'. Query: 'INSERT INTO f_scraper_banner_details(job_details_id, ad_id, client_id, zone_id, affiliateid, comments, pct_to_report, publisher_currency, sanity_check_enabled, status, error_code, report_date) VALUES (10274859, 321264, 0, 31926, 0, '', -1, 'USD', 1, 'FAILURE', 'INACTIVE_BANNER', '2016-06-28 04:00:00')'

mysql> table de réparation f_scraper_banner_details;

Cela a fonctionné pour moi

Mon problème provenait d'une mauvaise requête. J'ai référencé une table dans FROM le n'était pas référencé dans SELECT.

exemple:

   SELECT t.*,s.ticket_status as `ticket_status`
   FROM tickets_new t, ticket_status s, users u

, users uest ce qui causait le problème pour moi. La suppression de cela a résolu le problème.

Pour référence, c'était dans un environnement de développement CodeIgniter.

J'ai reçu ce message en écrivant dans une table après avoir réduit le ft_min_word_len (longueur minimale du mot en texte intégral). Pour le résoudre, recréez l'index en réparant la table.

mysqlcheck -r -f -uroot -p --use_frm nom_base

fera normalement l'affaire