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

108

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

#126 - Incorrect key file for table

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

Брайан
источник
3
Я получаю это и с видами
Эльзо Валуги
4
папка tmp имеет ограничение обычно 2 ГБ, попробуйте df -h, чтобы увидеть его
Эльзо Валуги
Если вы сделали это REPAIR TABLEи все еще получаете это, плюс есть место, /tmpвы можете попробовать просто перезагрузить сервер.
icc97 02

Ответы:

161

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

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

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

Монстры X
источник
4
Также у меня есть около 2 ГБ свободного места, и я получаю эту ошибку. Но моя база данных около 1,7 ГБ, а в базе данных есть таблица с ~ 1,5 млн строк. После очистки при свободном месте около 3,5-4Гб ошибка исчезает.
Сергей
2
В моей системе (Fedora 18) /tmpесть небольшая файловая система tmpfs, и у mysql не хватило места для записи туда временной таблицы. Мне пришлось установить tmpdirпеременную конфигурации, как указано на mysql.com
jcbwlkr
1
Хотя это может быть причиной, для меня это никогда не было связано с полным диском. Я получаю эту ошибку на инстансе Amazon RDS, выделенном для 10 ГБ, который заполнен только на 1%. Причиной также может быть нехватка памяти.
Cerin 02
2
вы можете установить tmpdir = / mysql_tmp или что-то в этом роде в my.cnf, и это должно быть в корневой файловой системе (какой бы большой она ни была)
Кевин Паркер
У меня также была такая же ошибка, хотя у меня есть дисковое пространство [root @ ADM-PROD-PERCONA-SL-RP-03 percona] # df -h Размер файловой системы Используемый Доступность Использование% Установлено на / dev / xvda1 7.8G 1.6G 6.1G 21% / devtmpfs 61G 80K 61G 1% / dev tmpfs 61G 0 61G 0% / dev / shm / dev / md0 3.0T 1.8T 1.2T 61% / mnt
Ашиш Карпе
35

Прежде всего, вы должны знать, что ключи и индексы в 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: Неверный ключевой файл для таблицы .

отложить92
источник
16

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

user387049
источник
9

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

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

junmats
источник
Я удалил все свои ключи и оптимизировал. Могу ли я получить эту ошибку, если мой запрос слишком медленный?
Брайан
Я не уверен, но, насколько я понимаю, эта ошибка не вызвана запросом. Вы уже пробовали ремонтировать?
junmats 06
3

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

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

jcampbell1
источник
Знаете ли вы, происходит ли это только при первом изменении настройки или это может произойти из-за слишком маленькой минимальной длины слова?
Y0lk
1

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

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

Баджранг
источник
1

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

Тебе надо:

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

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

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

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

Шон
источник
Мне удалось решить аналогичную проблему всего за один шаг: вы можете перестроить свою таблицу, используя свой текущий движок таблиц. Т.е., если вы используете myisam, используйте: ALTER IGNORE TABLE table ENGINE = MyISAM;
Шон Дауни
1

Перейти /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
BenD
источник
0

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

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

MigDus
источник
0

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

Не работает:

-- 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 не было.

Берни
источник
0
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;

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

Ашиш Карпе
источник
0

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

пример:

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

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

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

Ли Коклин
источник
0

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

Нико Шефер
источник
0

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

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

Энди
источник