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

J’ai reçu l’erreur suivante 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. Est-ce que quelqu’un sait ce qui pourrait être le problème?

Chaque fois que cela s’est produit, cela a été un disque dur dans mon expérience.

MODIFIER

Il est également intéressant de noter que cela peut être dû à un disque virtuel complet lorsque vous modifiez 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:

KEY est normalement synonyme d’ INDEX . L’atsortingbut de clé PRIMARY KEY peut également être spécifié en tant que clé uniquement lorsqu’il est donné dans une définition de colonne. Cela a été mis en œuvre pour la compatibilité avec d’autres systèmes de firebase database.


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 pourrait résoudre le problème temporairement. Si cela est fait pour vous, vous avez probablement un dossier tmp trop petit pour la taille des requêtes que vous essayez de faire. Vous pouvez alors décider ou faire en sorte que tmp plus grand, ou pour réduire vos requêtes! 😉

Parfois, tmp est assez gros mais est toujours plein, vous devrez effectuer un nettoyage manuel dans ces situations.

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


Regardez le message d’erreur complet que vous obtenez:

Fichier de clé incorrect pour la table ‘FILEPATH.MYI’; essayer de le réparer

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

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

  • si elle contient le nom d’une table réelle, cela signifie que cette table est très probablement corrompue et que vous devriez 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 corriger le problème:

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

 df -h 

Recherchez les processus qui ont des fichiers ouverts dans /tmp

 sudo lsof /tmp/**/* 

Puis umount /tmp et /var/tmp :

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

Supprimez ensuite le fichier de partition corrompu:

 rm -fv /usr/tmpDSK 

Ensuite, créez une nouvelle belle:

 /scripts/securetmp 

Notez qu’en éditant le script securetmp Perl, vous pouvez définir vous-même la taille du répertoire tmp. Cependant, 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.

Erreur # 126 se produit généralement lorsque vous avez une table endommagée. La meilleure façon de résoudre ce problème est d’effectuer une réparation. Cet article pourrait aider:

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

J’ai eu cette erreur lorsque j’ai défini ft_min_word_len = 2 dans my.cnf , ce qui abaisse la longueur minimale du mot dans un index de texte intégral à 2, par rapport à la valeur par défaut de 4.

Réparer la table a résolu le problème.

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

J’ai également fait face à ce problème et résolu par limite dans la requête, parce que les milliers d’enregistrements étaient là. Maintenant, ça marche 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 les deux ib_logfile0 et ib_logfile1.
  4. Redémarrer le service
 repair table myschema.mytable; 

J’ai corrigé ce problème avec:

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

Mai aide

  • Réf: MySQL: ALTER IGNORE TABLE donne “violation de contrainte d’intégrité”

Allez dans /etc/my.cnf et commentez tmpfs

 #tmpdir=/var/tmpfs 

Cela corrige 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 un tableau -> Cliquez sur le bouton Maintenance -> Réparer -> Utiliser FRM.

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

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 énoncés):

 -- 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 pas d’erreurs 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 

Puis l’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 venait d’une mauvaise requête. J’ai référencé une table dans FROM n’a pas été référencé dans SELECT.

Exemple:

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

, users u sont ce qui a causé le problème pour moi. Enlever ce qui a résolu le problème.

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