web-dev-qa-db-fra.com

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

J'ai eu 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 index. Est-ce que quelqu'un sait ce qui pourrait être le problème?

mysqlmysql-error-126
105
Brian

Chaque fois que cela s'est produit, c'est un disque complet selon mon expérience.

EDIT

Il convient également de noter que cela peut être dû à un disque virtuel complet lorsque vous modifiez une grande table, par exemple, si vous en avez configuré un. Vous pouvez mettre temporairement en commentaire la ligne du disque mémoire pour autoriser de telles opérations si vous ne pouvez pas en augmenter la taille.

157
Monsters X

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

KEY est normalement un synonyme de INDEX. L'attribut clé PRIMARY KEY peut aussi être spécifié simplement KEY 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 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 le problème temporairement. Si cela vous convient, vous avez probablement un dossier tmp trop petit pour la taille des requêtes que vous essayez d'effectuer. Vous pouvez ensuite décider ou rendre tmp plus gros, ou rendre vos requêtes plus petites! ;)

Parfois, tmp est assez gros mais reste 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 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 table REPAIR . 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 est mentionné 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 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.

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

Si vous identifiez que votre problème concerne 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 .

34
snooze92

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 sur disque sous une forme lisible par l'homme:

df -h

Trouver les processus qui ont des fichiers ouverts dans /tmp

Sudo lsof /tmp/**/*

Alors umount /tmp et /var/tmp:

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

Ensuite, supprimez le fichier de partition corrompu:

rm -fv /usr/tmpDSK

Puis créez-en un nouveau:

/scripts/securetmp

Notez qu'en modifiant le script securetmp Perl, vous pouvez définir manuellement la taille du répertoire tmp. Toutefois, le simple fait de l'exécuter a augmenté la taille du répertoire tmp sur notre serveur d'environ 450 Mo à 4,0 Go.

16
user387049

L'erreur n ° 126 se produit généralement lorsque vous avez une table corrompue. Le meilleur moyen de résoudre ce problème consiste à effectuer une réparation. Cet article pourrait aider:

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

9
junmats

J'ai eu cette erreur quand j'ai mis ft_min_Word_len = 2 dans my.cnf, qui réduit la longueur minimale de Word dans un index de texte intégral à 2, par défaut de 4.

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

3
jcampbell1

Essayez d'utiliser limit dans votre requête. C'est à cause du disque complet, 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 :)

1
Bajrang

Aller à /etc/my.cnf et commenter 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, l'espace n'était donc pas en cause.

/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
1
BenD

Je sais que c'est un sujet ancien, mais aucune des solutions mentionnées ne m'a fonctionné. J'ai fait quelque chose d'autre qui a fonctionné:

Tu dois:

  1. arrêtez le service MySQL:
  2. Ouvrez mysql\data
  3. Supprimez ib_logfile0 et ib_logfile1.
  4. Redémarrer le service
1
Hyder B.

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;

Mai aide

1
Sean
repair table myschema.mytable;
1
ThreaT

Maintenant, des autres réponses résolues pour moi. Il s'avère que le fait de renommer une colonne et un index dans la même requête a causé 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 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 a pas eu d'erreur avec la même requête sur MySQL 5.5.48.

0
bernie

Mon problème venait d'une mauvaise requête. J'ai référencé une table dans FROM le 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 est ce qui causait le problème pour moi. Enlever cela a résolu le problème.

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

0
Lee Cocklin

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

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

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

Ensuite, 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

0
Ashish Karpe