MySQL: # 126 - Arquivo de chave incorreto para a tabela

Recebi o seguinte erro de uma consulta MySQL.

#126 - Incorrect key file for table

Eu nem mesmo declarei uma chave para esta tabela, mas tenho índices. Alguém sabe qual poderia ser o problema?

Sempre que isso aconteceu, minha experiência foi um disco cheio.

EDITAR

Também é importante notar que isso pode ser causado por um ramdisk completo ao fazer coisas como alterar uma tabela grande se você tiver um ramdisk configurado. Você pode comentar temporariamente a linha do ramdisk para permitir tais operações se não puder aumentar o tamanho dela.

Em primeiro lugar, você deve saber que chaves e índices são sinônimos no MySQL. Se você olhar a documentação sobre a sintaxe CREATE TABLE , poderá ler:

KEYnormalmente é um sinônimo de INDEX. O atributo de chave PRIMARY KEYtambém pode ser especificado apenas KEYquando fornecido em uma definição de coluna. Isso foi implementado para compatibilidade com outros sistemas de banco de dados.

Agora, o tipo de erro que você está recebendo pode ser devido a duas coisas:

• Problemas de disco no servidor MySQL
• Chaves / tabelas corrompidas

No primeiro caso, você verá que adicionar um limite à sua consulta pode resolver o problema temporariamente. Se isso tmpfor suficiente para você, provavelmente você tem uma pasta muito pequena para o tamanho das consultas que está tentando fazer. Você pode então decidir ou aumentar tmpou diminuir suas consultas! ;)

Às vezes, tmpé grande o suficiente, mas ainda fica cheio, você precisará fazer uma limpeza manual nessas situações.

No segundo caso, existem problemas reais com os dados do MySQL. Se você puder inserir novamente os dados facilmente, recomendo apenas descartar / recriar a tabela e inserir novamente os dados. Se você não puder, tente consertar a mesa com a mesa REPAIR . É um processo geralmente demorado que pode muito bem falhar.

Veja a mensagem de erro completa que você recebe:

Arquivo de chave incorreto para a tabela 'FILEPATH.MYI'; tente consertá-lo

Ele menciona na mensagem que você pode tentar consertá-lo. Além disso, se você olhar o FILEPATH real que obtém, pode descobrir mais:

• se for algo parecido /tmp/#sql_ab34_23f, significa que o MySQL precisa criar uma tabela temporária devido ao tamanho da consulta. Ele armazena em / tmp, e que não há espaço suficiente em seu / tmp para essa tabela temporária.

• se ele contiver o nome de uma tabela real, significa que essa tabela muito provavelmente está corrompida e você deve repará-la.

Se você identificar que seu problema é com o tamanho de / tmp, basta ler esta resposta a uma pergunta semelhante para a correção: MySQL, Erro 126: Arquivo de chave incorreto para a tabela .

Seguir essas instruções me permitiu recriar meu diretório tmp e corrigir o problema:

Exibir todos os sistemas de arquivos e seu uso de disco em formato legível por humanos:

df -h

Encontre os processos que têm arquivos abertos no /tmp

sudo lsof /tmp/**/*

Então umount /tmpe /var/tmp:

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

Em seguida, remova o arquivo de partição corrompido:

rm -fv /usr/tmpDSK

Em seguida, crie um novo bom:

/scripts/securetmp

Observe que, ao editar o script Perl securetmp, você pode definir manualmente o tamanho do diretório tmp, no entanto, apenas a execução do script aumentou o tamanho do diretório tmp em nosso servidor de aproximadamente 450 MB para 4,0 GB.

O erro # 126 geralmente ocorre quando você obtém uma tabela corrompida. A melhor maneira de resolver isso é fazer um reparo. Este artigo pode ajudar:

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

Eu tenho esse erro quando eu definir ft_min_word_len = 2em my.cnf, o que reduz o comprimento de palavra mínimo em um índice de texto completo para 2, a partir do padrão de 4.

Reparar a mesa resolveu o problema.

Tente usar o limite em sua consulta. É por causa do disco cheio, como disse @Monsters X.

Também já enfrentei esse problema e resolvi pelo limite na consulta, pois os milhares de registros estavam lá. Agora funcionando bem :)

Eu sei que este é um tópico antigo, mas nenhuma das soluções mencionadas funcionou para mim. Eu fiz outra coisa que funcionou:

Você precisa:

1. pare o serviço MySQL:
2. Abra mysql \ data
3. Remova ib_logfile0 e ib_logfile1.
4. Reinicie o serviço

repair table myschema.mytable;

Eu resolvi esse problema com:

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

Maio ajuda

• Refs: MySQL: ALTER IGNORE TABLE fornece "violação de restrição de integridade"

Vá para /etc/my.cnfe comentetmpfs

#tmpdir=/var/tmpfs

Isso resolve o problema.

Executei o comando sugerido em outra resposta e, embora o diretório seja pequeno, estava vazio, portanto, o espaço não era o 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

Tente executar um comando de reparo para cada uma das tabelas envolvidas na consulta.

Use o administrador do MySQL, vá para Catálogo -> Selecione seu Catálogo -> Selecione uma tabela -> Clique no botão Manutenção -> Reparar -> Usar FRM.

Agora, das outras respostas resolveu para mim. Acontece que renomear uma coluna e um índice na mesma consulta causou o erro.

Não está funcionando:

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

Trabalhos (2 afirmações):

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

Isso foi no MariaDB 10.0.20. Não houve erros com a mesma consulta no MySQL 5.5.48.

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

Então existe o erro obtido:

 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 de reparo f_scraper_banner_details;

Isso funcionou para mim

Meu problema veio de uma consulta ruim. Eu referenciei uma tabela em FROM não foi referenciada em SELECT.

exemplo:

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

, users ué o que estava causando o problema para mim. Remover isso resolveu o problema.

Para referência, isso foi em um ambiente de desenvolvimento CodeIgniter.

Recebi esta mensagem ao escrever em uma tabela depois de reduzir o ft_min_word_len (comprimento mínimo da palavra do texto completo). Para resolvê-lo, recrie o índice reparando a tabela.

mysqlcheck -r -f -uroot -p --use_frm db_name

normalmente fará o truque