MySQL：＃126-表的密钥文件不正确

我从MySQL查询中收到以下错误。

#126 - Incorrect key file for table

我什至没有为该表声明键，但是我有索引。有谁知道可能是什么问题？

每次发生这种情况时，根据我的经验，它都是完整的磁盘。

编辑

还值得注意的是，如果配置了虚拟磁盘，那么在执行诸如更改大表之类的操作时，这可能是由于虚拟磁盘已满引起的。如果您不能增加ramdisk的大小，可以暂时将其注释掉以允许进行此类操作。

首先，您应该知道键和索引在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：table的密钥文件不正确。

遵循以下说明，我可以重新创建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脚本，您可以自己手动设置tmp目录的大小，但是仅运行该脚本会将服务器上tmp目录的大小从大约450MB增加到4.0GB。

当表损坏时，通常会发生错误＃126。解决此问题的最佳方法是执行维修。本文可能会有所帮助：

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

我得到这个错误，当我设置ft_min_word_len = 2在my.cnf，这降低了全文索引的最小字长为2，从4默认值。

修理桌子可以解决问题。

尝试在查询中使用限制。这是因为@Monsters X表示磁盘已满。

我也遇到了这个问题，并通过查询中的限制来解决，因为那里有成千上万的记录。现在工作良好:)

我知道这是一个古老的话题，但是提到的解决方案都不适合我。我做了其他有用的事情：

你需要：

1. 停止MySQL服务：
2. 打开mysql \ data
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;

可能会有所帮助

• 参考：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（全文本最小字长）后，写入表时收到此消息。要解决此问题，请通过修复表来重新创建索引。

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

通常会成功