MySQL: # 126 - Неверный ключевой файл для таблицы

Я получил следующую ошибку из запроса MySQL.

#126 - Incorrect key file for table

Я даже не объявил ключ для этой таблицы, но у меня есть индексы. Кто-нибудь знает в чем может быть проблема?

По моему опыту, каждый раз, когда это происходило, это был полный диск.

РЕДАКТИРОВАТЬ

Также стоит отметить, что это может быть вызвано полным ramdisk при выполнении таких вещей, как изменение большой таблицы, если у вас настроен ramdisk. Вы можете временно закомментировать строку ramdisk, чтобы разрешить такие операции, если вы не можете увеличить ее размер.

Прежде всего, вы должны знать, что ключи и индексы в MySQL являются синонимами. Если вы посмотрите документацию по синтаксису CREATE TABLE , вы можете прочитать:

KEYобычно является синонимом INDEX. Ключевой атрибут PRIMARY KEYтакже может быть указан в том виде, в котором он KEYуказан в определении столбца. Это было реализовано для совместимости с другими системами баз данных.

Ошибка, которую вы получаете, может быть вызвана двумя причинами:

• Проблемы с диском на сервере MySQL
• Поврежденные ключи / таблицы

В первом случае вы увидите, что добавление ограничения к вашему запросу может временно решить проблему. Если это сработает, у вас, вероятно, есть tmpпапка, которая слишком мала для размера запросов, которые вы пытаетесь выполнить. Затем вы можете решить: tmpувеличить или уменьшить количество запросов! ;)

Иногда tmpон достаточно велик, но все равно заполняется, в таких ситуациях вам нужно выполнить некоторую ручную очистку.

Во втором случае есть актуальные проблемы с данными MySQL. Если вы можете легко повторно вставить данные, я бы посоветовал просто отбросить / воссоздать таблицу и повторно вставить данные. Если вы не можете, вы можете попробовать отремонтировать стол на месте с помощью REPAIR table . Обычно это длительный процесс, который вполне может потерпеть неудачу.

Посмотрите полное сообщение об ошибке, которое вы получите:

Неверный ключевой файл для таблицы FILEPATH.MYI; попробуй отремонтировать это

В сообщении упоминается, что вы можете попробовать его отремонтировать. Кроме того, если вы посмотрите на фактический FILEPATH, который вы получите, вы сможете узнать больше:

• если это что-то вроде, /tmp/#sql_ab34_23fэто означает, что MySQL необходимо создать временную таблицу из-за размера запроса. Он хранит его в / tmp, и что в вашем / tmp недостаточно места для этой временной таблицы.

• если вместо этого он содержит имя реальной таблицы, это означает, что эта таблица, скорее всего, повреждена, и вам следует ее восстановить.

Если вы определили, что ваша проблема связана с размером / tmp, просто прочтите этот ответ на аналогичный вопрос об исправлении: MySQL, Ошибка 126: Неверный ключевой файл для таблицы .

Следуя этим инструкциям, я смог воссоздать каталог tmp и исправить проблему:

Отобразите все файловые системы и их использование на диске в удобочитаемой форме:

df -h

Найдите процессы, файлы которых открыты в /tmp

sudo lsof /tmp/**/*

Затем размонтируйте /tmpи /var/tmp:

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

Затем удалите поврежденный файл раздела:

rm -fv /usr/tmpDSK

Затем создайте новый красивый:

/scripts/securetmp

Обратите внимание, что, отредактировав Perl-скрипт securetmp, вы можете вручную установить размер каталога tmp самостоятельно, однако простой запуск скрипта увеличил размер каталога tmp на нашем сервере примерно с 450 МБ до 4,0 ГБ.

Ошибка № 126 обычно возникает при повреждении таблицы. Лучший способ решить эту проблему - произвести ремонт. Эта статья может помочь:

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

Я получил эту ошибку , когда я установил ft_min_word_len = 2в my.cnf, что снижает минимальную длину слов в полнотекстовом индексе 2, от значения по умолчанию 4.

Ремонт стола устранил проблему.

Попробуйте использовать ограничение в вашем запросе. Это из-за полного диска, как сказал @Monsters X.

Я также столкнулся с этой проблемой и решил с помощью ограничения в запросе, потому что там были тысячи записей. Теперь работает хорошо :)

Я знаю, что это старая тема, но ни одно из упомянутых решений не помогло мне. Я сделал еще кое-что, что сработало:

Тебе надо:

1. остановите службу MySQL:
2. Откройте mysql \ data
3. Удалите как ib_logfile0, так и ib_logfile1.
4. Перезапустите службу

repair table myschema.mytable;

Я исправил эту проблему с помощью:

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

Может помогает

• Ссылки: MySQL: ALTER IGNORE TABLE дает "нарушение ограничения целостности"

Перейти /etc/my.cnfи прокомментироватьtmpfs

#tmpdir=/var/tmpfs

Это решает проблему.

Я выполнил команду, предложенную в другом ответе, и, хотя каталог небольшой, он был пуст, поэтому проблема не была в пространстве.

/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

Попробуйте запустить команду восстановления для каждой из таблиц, участвующих в запросе.

Используйте администратора MySQL, перейдите в Каталог -> Выберите каталог -> Выберите таблицу -> Нажмите кнопку «Обслуживание» -> Восстановить -> Использовать FRM.

Теперь другие ответы решили это для меня. Оказалось, что переименование столбца и индекса в одном запросе вызвало ошибку.

Не работает:

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

Работы (2 заявления):

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

Это было на MariaDB 10.0.20. Ошибок с тем же запросом в MySQL 5.5.48 не было.

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

Тогда есть ошибка:

 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> таблица восстановления f_scraper_banner_details;

Это сработало для меня

Моя проблема возникла из-за неправильного запроса. Я ссылался на таблицу в FROM, на которую не ссылались в SELECT.

пример:

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

, users uэто то, что вызывало у меня проблему. Удаление решило проблему.

Для справки это было в среде разработки CodeIgniter.

Я получил это сообщение при записи в таблицу после уменьшения ft_min_word_len (минимальная длина слова для полного текста). Чтобы решить эту проблему, заново создайте индекс, исправив таблицу.

mysqlcheck -r -f -uroot -p --use_frm имя_бд

обычно добьется цели