MySQL: # 126 - File chiave errato per la tabella

Ho ricevuto il seguente errore da una query MySQL.

#126 - Incorrect key file for table

Non ho nemmeno dichiarato una chiave per questa tabella, ma ho gli indici. Qualcuno sa quale potrebbe essere il problema?

Ogni volta che è successo, nella mia esperienza è stato un disco pieno.

MODIFICARE

Vale anche la pena notare che questo può essere causato da un ramdisk completo quando si fanno cose come alterare una tabella di grandi dimensioni se si dispone di un ramdisk configurato. È possibile commentare temporaneamente la riga ramdisk per consentire tali operazioni se non è possibile aumentarne la dimensione.

Prima di tutto, dovresti sapere che le chiavi e gli indici sono sinonimi in MySQL. Se guardi la documentazione sulla sintassi CREATE TABLE , puoi leggere:

KEYè normalmente un sinonimo di INDEX. L'attributo chiave PRIMARY KEYpuò anche essere specificato come KEYse fosse fornito in una definizione di colonna. Questo è stato implementato per compatibilità con altri sistemi di database.

Ora, il tipo di errore che stai ricevendo può essere dovuto a due cose:

• Problemi relativi al disco sul server MySQL
• Chiavi / tabelle danneggiate

Nel primo caso, vedrai che l'aggiunta di un limite alla tua query potrebbe risolvere temporaneamente il problema. Se questo funziona per te, probabilmente hai una tmpcartella troppo piccola per le dimensioni delle query che stai tentando di fare. Puoi quindi decidere o tmpingrandire o ridurre le tue query! ;)

A volte, tmpè abbastanza grande ma si riempie ancora, dovrai fare un po 'di pulizia manuale in queste situazioni.

Nel secondo caso, ci sono problemi reali con i dati di MySQL. Se riesci a reinserire facilmente i dati, ti consiglio di eliminare / ricreare la tabella e reinserire i dati. Se non puoi, puoi provare a riparare il tavolo in posizione con il tavolo REPAIR . È un processo generalmente lungo che potrebbe benissimo fallire.

Guarda il messaggio di errore completo che ricevi:

File chiave non corretto per la tabella "FILEPATH.MYI"; prova a ripararlo

Nel messaggio viene menzionato che puoi provare a ripararlo. Inoltre, se guardi il FILEPATH effettivo che ottieni, puoi saperne di più:

• se è qualcosa di simile /tmp/#sql_ab34_23fsignifica che MySQL deve creare una tabella temporanea a causa delle dimensioni della query. Lo memorizza in / tmp e che non c'è abbastanza spazio in / tmp per quella tabella temporanea.

• se invece contiene il nome di una tabella effettiva, significa che questa tabella è molto probabilmente danneggiata e dovresti ripararla.

Se identifichi che il tuo problema è con la dimensione di / tmp, leggi questa risposta a una domanda simile per la correzione: MySQL, errore 126: file chiave non corretto per la tabella .

Seguire queste istruzioni mi ha permesso di ricreare la mia directory tmp e risolvere il problema:

Visualizza tutti i file system e il loro utilizzo del disco in un formato leggibile dall'uomo:

df -h

Trova i processi che hanno file aperti in /tmp

sudo lsof /tmp/**/*

Quindi smonta /tmpe /var/tmp:

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

Quindi rimuovere il file di partizione danneggiato:

rm -fv /usr/tmpDSK

Quindi creane uno nuovo:

/scripts/securetmp

Si noti che modificando lo script Perl securetmp è possibile impostare manualmente la dimensione della directory tmp da soli, tuttavia solo eseguendo lo script è aumentata la dimensione della directory tmp sul nostro server da circa 450 MB a 4,0 GB.

L'errore # 126 di solito si verifica quando hai una tabella danneggiata. Il modo migliore per risolvere questo problema è eseguire la riparazione. Questo articolo potrebbe aiutare:

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

Ho ottenuto questo errore quando ho impostato ft_min_word_len = 2in my.cnf, che riduce la lunghezza minima parola in un indice completo di 2, dal valore predefinito di 4.

La riparazione della tabella ha risolto il problema.

Prova a utilizzare il limite nella tua query. È a causa del disco pieno come detto da @Monsters X.

Ho anche affrontato questo problema e risolto per limite nella query, perché c'erano migliaia di record. Ora funziona bene :)

So che questo è un vecchio argomento ma nessuna delle soluzioni menzionate ha funzionato per me. Ho fatto qualcos'altro che ha funzionato:

Devi:

1. interrompere il servizio MySQL:
2. Apri mysql \ data
3. Rimuovi ib_logfile0 e ib_logfile1.
4. Riavvia il servizio

repair table myschema.mytable;

Ho risolto questo problema con:

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

Può aiutare

• Refs: MySQL: ALTER IGNORE TABLE restituisce "Violazione del vincolo di integrità"

Vai a /etc/my.cnfe commentatmpfs

#tmpdir=/var/tmpfs

Questo risolve il problema.

Ho eseguito il comando suggerito in un'altra risposta e mentre la directory è piccola, era vuota, quindi lo spazio non era il problema.

/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

Prova a eseguire un comando di riparazione per ciascuna delle tabelle coinvolte nella query.

Usa l'amministratore MySQL, vai su Catalogo -> Seleziona il tuo catalogo -> Seleziona una tabella -> Fai clic sul pulsante Manutenzione -> Ripara -> Usa FRM.

Ora delle altre risposte l'ho risolto per me. Risulta che la ridenominazione di una colonna e di un indice nella stessa query ha causato l'errore.

Non funziona:

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

Opere (2 dichiarazioni):

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

Questo era su MariaDB 10.0.20. Non ci sono stati errori con la stessa query su MySQL 5.5.48.

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

Quindi esiste un errore:

 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> tabella di riparazione f_scraper_banner_details;

Questo ha funzionato per me

Il mio problema derivava da una cattiva query. Ho fatto riferimento a una tabella in FROM che non è stato referenziato in SELECT.

esempio:

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

, users uè ciò che ha causato il problema per me. La rimozione ha risolto il problema.

Per riferimento questo era in un ambiente di sviluppo CodeIgniter.

Ho ricevuto questo messaggio durante la scrittura su una tabella dopo aver ridotto ft_min_word_len (lunghezza minima della parola del testo completo). Per risolverlo, ricreare l'indice riparando la tabella.

mysqlcheck -r -f -uroot -p --use_frm nome_db

normalmente farà il trucco