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

Question

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

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

#126 - Incorrect key file for table

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

109

mysql mysql-error-126

Источник

user232495 06 янв '10 в 05:01

14 ответов

Другие вопросы по тегам mysql mysql-error-126

user634423 08 дек '11 в 16:48 2011-12-08 16:48 · Answer 1 · 2011-12-08 16:48

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

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

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

user1994863 09 дек '13 в 10:13 2013-12-09 10:13 · Answer 2 · 2013-12-09 10:13

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

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

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

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

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

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

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

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

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

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

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

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

user387049 06 сен '12 в 15:18 2012-09-06 15:18 · Answer 3 · 2012-09-06 15:18

Следование этим инструкциям позволило мне воссоздать каталог 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 ГБ.

user82350 06 янв '10 в 05:13 2010-01-06 05:13 · Answer 4 · 2010-01-06 05:13

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

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

10

Источник

user82350 06 янв '10 в 05:13

user20512 14 авг '14 в 16:46 2014-08-14 16:46 · Answer 5 · 2014-08-14 16:46

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

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

3

Источник

user20512 14 авг '14 в 16:46

user848612 22 авг '14 в 10:20 2014-08-22 10:20 · Answer 6 · 2014-08-22 10:20

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

Вам нужно:

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

2

Источник

user848612 22 авг '14 в 10:20

user5067146 30 июн '15 в 21:17 2015-06-30 21:17 · Answer 7 · 2015-06-30 21:17

Идти к /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

user1191027 12 сен '14 в 10:19 2014-09-12 10:19 · Answer 8 · 2014-09-12 10:19

repair table myschema.mytable;

1

Источник

user1191027 12 сен '14 в 10:19

user603128 15 фев '13 в 06:45 2013-02-15 06:45 · Answer 9 · 2013-02-15 06:45

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

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

1

Источник

user603128 15 фев '13 в 06:45

user1030527 05 апр '16 в 15:24 2016-04-05 15:24 · Answer 10 · 2016-04-05 15:24

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

Не работает:

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

user1871377 14 ноя '14 в 16:22 2014-11-14 16:22 · Answer 11 · 2014-11-14 16:22

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

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

Май помогает

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

1

Источник

user1871377 14 ноя '14 в 16:22

user3753130 28 сен '20 в 22:01 2020-09-28 22:01 · Answer 12 · 2020-09-28 22:01

Пришел сюда в поисках - "#1034 - Неверный ключевой файл для таблицы test; попробуйте исправить"

Это вызвано добавлением кодировки в индексированное Enum (может быть таким же, как и в других полях) с Mysql 8.0.21.

CREATE TABLE `test` (
`enumVal` ENUM( 'val1' ) NOT NULL
) ENGINE = MYISAM;
ALTER TABLE `test` ADD INDEX ( `enumVal` );

ALTER TABLE  `test` CHANGE  `enumVal`  `enumVal` ENUM(  'val1') CHARACTER SET utf8 COLLATE utf8_bin NOT NULL;

Использование решения - отбросить индекс перед изменением.

ALTER TABLE `test` ADD INDEX ( `enumVal` );

user6200622 12 авг '16 в 17:40 2016-08-12 17:40 · Answer 13 · 2016-08-12 17:40

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

пример:

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

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

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

user727811 09 апр '12 в 00:13 2012-04-09 00:13 · Answer 14 · 2012-04-09 00:13

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

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

0

Источник

user727811 09 апр '12 в 00:13

user3425138 01 июл '16 в 07:21 2016-07-01 07:21 · Answer 15 · 2016-07-01 07:21

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;

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

user1705555 25 мар '20 в 15:39 2020-03-25 15:39 · Answer 16 · 2020-03-25 15:39

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

0

Источник

user1705555 25 мар '20 в 15:39

user412356 24 июл '20 в 23:05 2020-07-24 23:05 · Answer 17 · 2020-07-24 23:05

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

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

0

Источник

user412356 24 июл '20 в 23:05