MySQL: # 126 - Niepoprawny plik klucza dla tabeli

Otrzymałem następujący błąd z zapytania MySQL.

#126 - Incorrect key file for table

Nawet nie zadeklarowałem klucza do tej tabeli, ale mam indeksy. Czy ktoś wie, co może być problemem?

Za każdym razem, gdy to się stało, z mojego doświadczenia wynika, że ​​był to pełny dysk.

EDYTOWAĆ

Warto również zauważyć, że może to być spowodowane pełnym ramdyskiem, gdy robisz takie rzeczy, jak zmienianie dużej tabeli, jeśli masz skonfigurowany ramdysk. Możesz tymczasowo zakomentować linię ramdysku, aby zezwolić na takie operacje, jeśli nie możesz zwiększyć jej rozmiaru.

Przede wszystkim powinieneś wiedzieć, że klucze i indeksy są synonimami w MySQL. Jeśli spojrzysz na dokumentację dotyczącą składni CREATE TABLE , możesz przeczytać:

KEYjest zwykle synonimem INDEX. Atrybut klucza PRIMARY KEYmożna również określić tak samo, jak w KEYprzypadku podania w definicji kolumny. Zostało to zaimplementowane w celu zapewnienia zgodności z innymi systemami baz danych.

Teraz rodzaj błędu, który otrzymujesz, może wynikać z dwóch rzeczy:

• Problemy z dyskiem na serwerze MySQL
• Uszkodzone klucze / tabele

W pierwszym przypadku zobaczysz, że dodanie ograniczenia do zapytania może tymczasowo rozwiązać problem. Jeśli to zrobi za Ciebie, prawdopodobnie masz tmpfolder, który jest za mały w stosunku do rozmiaru zapytań, które próbujesz wykonać. Możesz wtedy zdecydować lub zrobićtmp powiększyć lub zmniejszyć zapytania! ;)

Czasami, tmp jest wystarczająco duży, ale nadal się zapełnia, w takich sytuacjach należy wykonać ręczne czyszczenie.

W drugim przypadku istnieją rzeczywiste problemy z danymi MySQL. Jeśli możesz łatwo ponownie wstawić dane, radziłbym po prostu upuścić / ponownie utworzyć tabelę i ponownie wstawić dane. Jeśli nie możesz, możesz spróbować naprawić stół na miejscu za pomocą stołu REPAIR . Jest to ogólnie długotrwały proces, który może się nie powieść.

Spójrz na pełny komunikat o błędzie, jaki otrzymujesz:

Niepoprawny plik kluczy dla tabeli „FILEPATH.MYI”; spróbuj to naprawić

Wspomina w komunikacie, że możesz spróbować go naprawić. Ponadto, jeśli spojrzysz na rzeczywistą otrzymaną ścieżkę FILEPATH, możesz dowiedzieć się więcej:

• jeśli jest coś podobnego /tmp/#sql_ab34_23f, oznacza to, że MySQL musi utworzyć tabelę tymczasową ze względu na rozmiar zapytania. Przechowuje go w / tmp i że w twoim / tmp nie ma wystarczającej ilości miejsca dla tej tymczasowej tabeli.

• jeśli zamiast tego zawiera nazwę rzeczywistej tabeli, oznacza to, że jest ona prawdopodobnie uszkodzona i należy ją naprawić.

Jeśli stwierdzisz, że problem dotyczy rozmiaru / tmp, po prostu przeczytaj tę odpowiedź na podobne pytanie w celu rozwiązania problemu: MySQL, Błąd 126: Nieprawidłowy plik klucza dla tabeli .

Wykonanie tych instrukcji pozwoliło mi ponownie utworzyć katalog tmp i rozwiązać problem:

Wyświetl wszystkie systemy plików i ich wykorzystanie na dysku w postaci czytelnej dla człowieka:

df -h

Znajdź procesy, w których są otwarte pliki /tmp

sudo lsof /tmp/**/*

Następnie umount /tmpi /var/tmp:

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

Następnie usuń uszkodzony plik partycji:

rm -fv /usr/tmpDSK

Następnie utwórz nowy ładny:

/scripts/securetmp

Zwróć uwagę, że edytując skrypt securetmp Perl, możesz ręcznie ustawić rozmiar katalogu tmp, jednak samo uruchomienie skryptu zwiększyło rozmiar katalogu tmp na naszym serwerze z około 450 MB do 4,0 GB.

Błąd # 126 zwykle występuje, gdy masz uszkodzoną tabelę. Najlepszym sposobem rozwiązania tego problemu jest naprawa. Ten artykuł może pomóc:

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

Dostałem ten błąd, gdy ustawiony ft_min_word_len = 2wmy.cnf , co obniża Minimalna długość słowa w pełnym indeksu tekstowego do 2, od dnia 4 domyślnie.

Naprawienie stołu rozwiązało problem.

Spróbuj użyć limitu w swoim zapytaniu. To z powodu pełnego dysku, jak powiedział @Monsters X.

Zmierzyłem się również z tym problemem i rozwiązałem go przez ograniczenie zapytania, ponieważ były tam tysiące rekordów. Teraz działa dobrze :)

Wiem, że to stary temat, ale żadne z wymienionych rozwiązań nie zadziałało. Zrobiłem coś innego, co zadziałało:

Musisz:

1. zatrzymaj usługę MySQL:
2. Otwórz mysql \ data
3. Usuń zarówno ib_logfile0, jak i ib_logfile1.
4. Uruchom ponownie usługę

repair table myschema.mytable;

Naprawiłem ten problem z:

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

Może pomaga

• Odniesienia: MySQL: ALTER IGNORE TABLE podaje „Naruszenie ograniczenia integralności”

Przejdź do /etc/my.cnfi skomentujtmpfs

#tmpdir=/var/tmpfs

To rozwiązuje problem.

Uruchomiłem polecenie zasugerowane w innej odpowiedzi i chociaż katalog jest mały, był pusty, więc nie było problemu.

/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

Spróbuj uruchomić polecenie naprawy dla każdej tabeli, której dotyczy zapytanie.

Użyj administratora MySQL, przejdź do Katalog -> Wybierz katalog -> Wybierz tabelę -> Kliknij przycisk Konserwacja -> Napraw -> Użyj FRM.

Teraz inne odpowiedzi rozwiązały to za mnie. Okazuje się, że zmiana nazwy kolumny i indeksu w tym samym zapytaniu spowodowała błąd.

Nie działa:

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

Prace (2 wypowiedzi):

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

To było w MariaDB 10.0.20. Nie było błędów w tym samym zapytaniu w MySQL 5.5.48.

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

Wystąpił błąd:

 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> tabela napraw f_scraper_banner_details;

To zadziałało dla mnie

Mój problem pochodzi ze złego zapytania. Odwołałem się do tabeli w FROM, do której nie odwołano się w SELECT.

przykład:

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

, users ujest przyczyną tego problemu. Usunięcie tego rozwiązało problem.

Dla porównania było to w środowisku deweloperskim CodeIgniter.

Otrzymałem ten komunikat podczas pisania do tabeli po zmniejszeniu ft_min_word_len (minimalna długość słowa w pełnym tekście). Aby go rozwiązać, ponownie utwórz indeks, naprawiając tabelę.

mysqlcheck -r -f -uroot -p --use_frm nazwa_bazy

normalnie załatwi sprawę