MySQL：＃126 – 表格的密钥文件不正确
我从MySQL查询中得到以下错误。
#126 - Incorrect key file for table
我甚至没有为这个表格声明一个关键字，但我确实有索引。 有谁知道可能是什么问题？
每次发生这种情况，根据我的经验，这是一个完整的磁盘。
编辑
另外值得一提的是，如果您configuration了虚拟硬盘，在更改大型表格时，可能会由于使用完整的虚拟硬盘而导致这种情况。 如果你不能增加它的大小，你可以临时注释掉ramdisk行来允许这样的操作。
首先，你应该知道键和索引是MySQL中的同义词。 如果您查看有关CREATE TABLE语法的文档，您可以阅读：
KEY通常是INDEX的同义词。 当在列定义中给出时，键属性PRIMARY KEY也可以被指定为KEY。 这是为了与其他数据库系统兼容而实现的。
现在，你得到的错误可能是由于两件事情：
- MySQL服务器上的磁盘问题
- 损坏的键/表
在第一种情况下，您会看到为查询添加限制可能会暂时解决问题。 如果这样做对你来说，你可能有一个tmp文件夹，对于你想要做的查询的大小太小了。 然后，您可以决定或使tmp更大，或使您的查询更小！ ;）
有时， tmp足够大，但仍然满，你需要在这些情况下做一些手动清理。
在第二种情况下，MySQL的数据存在实际问题。 如果您可以轻松地重新插入数据，我build议只删除/重新创build表，然后重新插入数据。 如果你不能，你可以尝试用REPAIR表修理表格 。 这是一个非常漫长的过程，可能会失败。
看看你得到的完整的错误信息 ：
表'FILEPATH.MYI'的密钥文件不正确; 尝试修复它
它在消息中提到，你可以尝试修复它。 另外，如果你看看你得到的实际FILEPATH，你可以find更多：
-
如果它是
/tmp/#sql_ab34_23f这意味着MySQL需要创build一个临时表，因为查询的大小。 它将其存储在/ tmp中，并且您的/ tmp中没有足够的空间用于临时表。 -
如果它包含实际表的名称，则意味着该表很可能已损坏，您应该修复它。
如果你确定你的问题是/ tmp的大小的话，只要阅读这个问题就可以得到一个类似的问题： MySQL，错误126：表的错误密钥文件 。
遵循这些指示允许我重新创build我的tmp目录并解决问题：
以可读forms显示所有文件系统及其磁盘使用情况：
df -h
find文件在/tmp打开的进程
sudo lsof /tmp/**/*
然后，umount /tmp和/var/tmp ：
umount -l /tmp umount -l /var/tmp
然后删除损坏的分区文件：
rm -fv /usr/tmpDSK
然后创build一个不错的新的：
/scripts/securetmp
请注意，通过编辑securetmp Perl脚本，您可以自己手动设置tmp目录的大小，但是只需运行该脚本即可将我们的服务器上tmp目录的大小从大约450MB增加到4.0GB。
错误＃126通常发生在有损坏的表格时。 解决这个问题的最好方法是进行维修。 本文可能有所帮助：
当我在my.cnf设置ft_min_word_len = 2时，出现这个错误，它将全文索引中的最小字长度从默认值4降低到2。
修复表格修复了这个问题。
尝试在查询中使用限制。 这是因为@Monsters X所说的完整磁盘。
我也面临这个问题，并通过查询限制解决，因为成千上万的logging在那里。 现在工作很好:)
我知道这是一个古老的话题，但没有提到的解决scheme为我工作。 我做了一些其他的工作：
你需要：
- 停止MySQL服务：
- 打开mysql \ data
- 除去ib_logfile0和ib_logfile1。
- 重新启动服务
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
这解决了这个问题。
我运行了另一个答案中build议的命令，而目录很小时，它是空的，所以空间不是问题。
/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
尝试为查询中涉及的每个表运行修复命令。
使用MySQLpipe理员，进入目录 – >select你的目录 – >select一个表格 – >点击维护button – >修复 – >使用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开发环境。
