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

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

#126 - Incorrect key file for table

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

Ответ 1

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

ИЗМЕНИТЬ

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

Ответ 2

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

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

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

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

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

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

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

Посмотрите на полное сообщение об ошибке:

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

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

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

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

Ответ 3

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

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

df -h

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

sudo lsof /tmp/**/*

Затем umount /tmp и /var/tmp:

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

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

rm -fv /usr/tmpDSK

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

/scripts/securetmp

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

Ответ 4

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

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

Ответ 5

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

Восстановление таблицы устраняет проблему.

Ответ 6

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

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

Ответ 7

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

Вам необходимо:

остановить службу MySQL:
Откройте mysql\datali >
Удалите оба ib_logfile0 и ib_logfile1.
Перезапустите службу

Ответ 8

repair table myschema.mytable;

Ответ 9

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

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

Может помочь

Refs: MySQL: ALTER IGNORE TABLE дает "Нарушение ограничения целостности"

Ответ 10

Перейдите к /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

Ответ 11

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

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

Ответ 12

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

Не работает:

-- 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.

Ответ 13

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;

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

Ответ 14

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

Пример:

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

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

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