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

Я отримав таку помилку в запиті MySQL.

#126 - Incorrect key file for table

Я навіть не оголосив ключ для цієї таблиці, але в мене є індекси. Хтось знає, що може бути проблемою?

Кожен раз, коли це сталося, на моєму досвіді це був повний диск.

EDIT

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

Перш за все, ви повинні знати, що ключі та індекси є синонімами в MySQL. Якщо ви подивитеся на документацію про синтаксис CREATE TABLE , ви можете прочитати:

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

Тепер помилка, яку ви отримуєте, може бути пов’язана з двома речами:

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

У першому випадку ви побачите, що додавання ліміту до запиту може тимчасово вирішити проблему. Якщо це робить це для вас, напевно, у вас є tmpпапка, яка занадто мала для розміру запитів, які ви намагаєтеся зробити. Потім ви можете вирішити або збільшити tmpмасштаб, або зробити ваші запити меншими! ;)

Іноді, tmpдосить великий, але все-таки заповнюється, в цих ситуаціях потрібно буде зробити чистку вручну.

У другому випадку є актуальні проблеми з даними MySQL. Якщо ви можете легко вставити дані, я б радив просто скинути / заново створити таблицю та знову вставити дані. Якщо ви не можете, спробуйте відновити таблицю на місці за допомогою таблиці REPAIR . Це, як правило, тривалий процес, який може бути дуже невдалим.

Подивіться повне повідомлення про помилку, яке ви отримуєте:

Неправильний файл ключів для таблиці "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

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

Помилка № 126 зазвичай виникає, коли ви отримали корумповану таблицю. Найкращий спосіб вирішити це - виконати ремонт. Ця стаття може допомогти:

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

Я отримав цю помилку , коли я встановив ft_min_word_len = 2уmy.cnf , що знижує мінімальну довжину слів в повнотекстовому індексі 2, від значення за замовчуванням 4.

Ремонт таблиці вирішив проблему.

Спробуйте використовувати ліміт у своєму запиті. Це через повний диск, як сказав @Monsters X.

Я також зіткнувся з цією проблемою і вирішив обмежено в запиті, тому що тисячі записів були там. Зараз добре працюємо :)

Я знаю, що це стара тема, але жоден із згаданих рішень не працював на мене. Я зробив щось інше, що спрацювало:

Тобі потрібно:

1. зупиніть службу MySQL:
2. Відкрити дані mysql \
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;

Травень допомагає

• Refs: 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 (повна довжина тексту, min хвилини слова) Щоб вирішити це, заново створіть індекс, відремонтувавши таблицю.

mysqlcheck -r -f -uroot -p --use_frm db_name

зазвичай робитимуть трюк