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

Question

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

#126 - Incorrect key file for table

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

Answer 1

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

EDIT

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

Answer 2

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

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

---

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

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

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

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

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

---

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

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

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

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

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

---

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

Answer 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

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

Answer 4

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

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

Answer 5

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

Исправление проблемы с таблицей.

Answer 6

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

Answer 7

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

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

май помогает

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

Answer 8

repair table myschema.mytable;

Answer 9

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

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

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

Answer 10

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

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