web-dev-qa-db-de.com

MySQL: # 126 - Falsche Schlüsseldatei für Tabelle

Ich habe den folgenden Fehler von einer MySQL-Abfrage erhalten.

#126 - Incorrect key file for table

Ich habe nicht einmal einen Schlüssel für diese Tabelle deklariert, aber ich habe Indizes. Weiß jemand woran das liegen könnte?

105
Brian

Jedes Mal, wenn dies passiert ist, war es meiner Erfahrung nach eine volle Festplatte.

EDIT

Es ist auch erwähnenswert, dass dies durch eine vollständige Ramdisk verursacht werden kann, wenn Sie beispielsweise eine große Tabelle ändern, wenn Sie eine Ramdisk konfiguriert haben. Sie können die Ramdisk-Zeile vorübergehend auskommentieren, um solche Vorgänge zuzulassen, wenn Sie sie nicht vergrößern können.

157
Monsters X

Zunächst sollten Sie wissen, dass Schlüssel und Indizes in MySQL Synonyme sind. Wenn Sie sich die Dokumentation zu CREATE TABLE Syntax ansehen, können Sie lesen:

KEY ist normalerweise ein Synonym für INDEX. Das Schlüsselattribut PRIMARY KEY kann auch als nur KEY angegeben werden, wenn dies in einer Spaltendefinition angegeben wird. Dies wurde aus Kompatibilitätsgründen mit anderen Datenbanksystemen implementiert.


Die Art des Fehlers, den Sie erhalten, kann auf zwei Dinge zurückzuführen sein:

  • Festplattenprobleme auf dem MySQL-Server
  • Beschädigte Schlüssel/Tabellen

Im ersten Fall werden Sie feststellen, dass das Problem möglicherweise vorübergehend behoben wird, wenn Sie Ihrer Abfrage ein Limit hinzufügen. Wenn das für Sie erledigt ist, haben Sie wahrscheinlich einen tmp -Ordner, der zu klein für die Größe der Abfragen ist, die Sie ausführen möchten. Sie können dann entscheiden, ob Sie tmp vergrößern oder Ihre Abfragen verkleinern möchten! ;)

Manchmal ist tmp groß genug, wird aber trotzdem voll. In diesen Situationen müssen Sie einige manuelle Bereinigungen vornehmen.

Im zweiten Fall gibt es aktuelle Probleme mit den Daten von MySQL. Wenn Sie die Daten einfach wieder einfügen können, würde ich empfehlen, die Tabelle einfach zu löschen/neu zu erstellen und die Daten erneut einzufügen. Wenn dies nicht möglich ist, können Sie versuchen, die Tabelle mit REPAIR table zu reparieren. Es ist ein allgemein langwieriger Prozess, der sehr gut scheitern kann.


Schauen Sie sich die vollständige Fehlermeldung an , die Sie erhalten:

Falsche Schlüsseldatei für Tabelle 'FILEPATH.MYI'; versuchen Sie es zu reparieren

In der Nachricht wird erwähnt, dass Sie versuchen können, es zu reparieren. Wenn Sie sich auch den tatsächlichen FILEPATH ansehen, den Sie erhalten, können Sie mehr herausfinden:

  • wenn es so etwas ist wie /tmp/#sql_ab34_23f bedeutet, dass MySQL aufgrund der Abfragegröße eine temporäre Tabelle erstellen muss. Es speichert es in/tmp und dass in Ihrem/tmp nicht genug Platz für diese temporäre Tabelle ist.

  • wenn es stattdessen den Namen einer tatsächlichen Tabelle enthält, bedeutet dies, dass diese Tabelle höchstwahrscheinlich beschädigt ist und Sie sie reparieren sollten.


Wenn Sie feststellen, dass Ihr Problem mit der Größe von/tmp zusammenhängt, lesen Sie einfach diese Antwort auf eine ähnliche Frage zum Fix: MySQL, Fehler 126: Falsche Schlüsseldatei für Tabelle .

34
snooze92

Durch Befolgen dieser Anweisungen konnte ich mein tmp-Verzeichnis neu erstellen und das Problem beheben:

Zeigen Sie alle Dateisysteme und deren Datenträgerverwendung in lesbarer Form an:

df -h

Finden Sie die Prozesse, bei denen Dateien geöffnet sind, in /tmp

Sudo lsof /tmp/**/*

Dann umount /tmp Und /var/tmp:

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

Entfernen Sie dann die beschädigte Partitionsdatei:

rm -fv /usr/tmpDSK

Dann erstelle eine schöne neue:

/scripts/securetmp

Beachten Sie, dass Sie durch Bearbeiten des securetmp-Perl-Skripts die Größe des tmp-Verzeichnisses manuell festlegen können. Durch einfaches Ausführen des Skripts wurde jedoch die Größe des tmp-Verzeichnisses auf unserem Server von ungefähr 450 MB auf 4,0 GB erhöht.

16
user387049

Fehler # 126 tritt normalerweise auf, wenn Sie eine beschädigte Tabelle haben. Der beste Weg, dies zu lösen, ist die Durchführung einer Reparatur. Dieser Artikel könnte helfen:

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

9
junmats

Ich habe diesen Fehler erhalten, als ich ft_min_Word_len = 2 im my.cnf, wodurch die minimale Wortlänge in einem Volltextindex von 4 auf 2 verringert wird.

Das Reparieren des Tisches hat das Problem behoben.

3
jcampbell1

Versuchen Sie Limit in Ihrer Abfrage zu verwenden. Es ist wegen der vollen Festplatte, wie von @Monsters X gesagt.

Ich habe mich auch mit diesem Problem auseinandergesetzt und es durch Abfragebegrenzung gelöst, weil die Tausenden von Datensätzen da waren. Jetzt funktioniert es gut :)

1
Bajrang

Gehe zu /etc/my.cnf und auskommentieren tmpfs

#tmpdir=/var/tmpfs

Dies behebt das Problem.

Ich habe den in einer anderen Antwort vorgeschlagenen Befehl ausgeführt, und obwohl das Verzeichnis klein ist, war es leer, sodass der Speicherplatz nicht das Problem war.

/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

Ich weiß, dass dies ein altes Thema ist, aber keine der genannten Lösungen hat für mich funktioniert. Ich habe etwas anderes gemacht, das funktioniert hat:

Du brauchst:

  1. stoppen Sie den MySQL-Dienst:
  2. Öffnen Sie mysql\data
  3. Entfernen Sie sowohl ib_logfile0 als auch ib_logfile1.
  4. Starten Sie den Dienst neu
1
Hyder B.

Ich habe dieses Problem behoben mit:

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

Mai hilft

1
Sean
repair table myschema.mytable;
1
ThreaT

Jetzt haben die anderen Antworten es für mich gelöst. Es stellte sich heraus, dass das Umbenennen einer Spalte und eines Indexes in derselben Abfrage den Fehler verursacht hat.

Funktioniert nicht:

-- 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);

Werke (2 Aussagen):

-- 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);

Dies war auf MariaDB 10.0.20. Es gab keine Fehler mit derselben Abfrage in MySQL 5.5.48.

0
bernie

Mein Problem ergab sich aus einer schlechten Abfrage. Ich habe auf eine Tabelle in FROM verwiesen, auf die in SELECT nicht verwiesen wurde.

beispiel:

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

, users u hat das Problem für mich verursacht. Das Entfernen löste das Problem.

Als Referenz diente dies in einer CodeIgniter-Entwicklungsumgebung.

0
Lee Cocklin

Versuchen Sie, einen Reparaturbefehl für jede der an der Abfrage beteiligten Tabellen auszuführen.

Verwenden Sie den MySQL-Administrator, gehen Sie zu Katalog -> Wählen Sie Ihren Katalog aus -> Wählen Sie eine Tabelle aus -> Klicken Sie auf die Schaltfläche Wartung -> Reparieren -> FRM verwenden.

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

Dann liegt ein Fehler vor:

 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> repair table f_scraper_banner_details;

Das hat bei mir funktioniert

0
Ashish Karpe