我从MySQL查询中收到以下错误。
#126 - Incorrect key file for table
我甚至没有宣布这张桌子的钥匙，但我确实有索引。有谁知道可能是什么问题？
答案 0 :(得分：156)
每次发生这种情况，根据我的经验，这是一个完整的磁盘。
修改
值得注意的是，如果你配置了ramdisk，那么在执行诸如更改大表之类的操作时，这可能是由完整的ramdisk引起的。如果你不能增加它的大小，你可以暂时注释掉ramdisk行以允许这样的操作。
答案 1 :(得分：34)
首先，您应该知道密钥和索引是MySQL中的同义词。如果您查看有关CREATE TABLE Syntax的文档，您可以阅读：
KEY通常是INDEX的同义词。在列定义中给出时，关键属性PRIMARY KEY也可以指定为KEY。这是为了与其他数据库系统兼容而实现的。
现在，您遇到的错误可能是由两件事造成的：
在第一种情况下，您会看到为查询添加限制可能会暂时解决问题。如果这样做适合您，您可能有一个tmp文件夹，该文件夹对于您尝试执行的查询而言太小。然后，您可以决定或使tmp更大，或者让您的查询更小！ ;）
有时，tmp足够大但仍然满满，在这些情况下你需要做一些手动清理。
在第二种情况下，MySQL的数据存在实际问题。如果您可以轻松地重新插入数据，我建议只需删除/重新创建表，然后重新插入数据。如果你不能，你可以尝试使用REPAIR table修复表格。这是一个通常很长的过程，很可能会失败。
查看完整错误消息：
表'FILEPATH.MYI'的密钥文件不正确;尝试修复它
在消息中提到您可以尝试修复它。另外，如果你看一下你得到的实际FILEPATH，你可以找到更多：
如果它类似于/tmp/#sql_ab34_23f，则意味着MySQL需要根据查询大小创建临时表。它将它存储在/ tmp中，并且/ tmp中没有足够的空间用于该临时表。
如果它包含实际表的名称，则表示该表很可能已损坏，您应该修复它。
如果您发现问题的大小为/ tmp，请阅读此问题的答案以获得修补程序的类似问题：MySQL, Error 126: Incorrect key file for table。
答案 2 :(得分：16)
按照这些说明允许我重新创建我的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目录的大小从大约450MB增加到4.0GB。
答案 3 :(得分：9)
错误＃126通常在您有一个损坏的表时发生。解决此问题的最佳方法是执行修复。 本文可能有所帮助：
答案 4 :(得分：2)
我在ft_min_word_len = 2中设置my.cnf时出现此错误，它将全文索引中的最小字长降低为2，默认值为4。
修复表解决了问题。
答案 5 :(得分：1)
repair table myschema.mytable;
答案 6 :(得分：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
答案 7 :(得分：1)
我用以下方法解决了这个问题：
ALTER TABLE table ENGINE MyISAM;
ALTER IGNORE TABLE table ADD UNIQUE INDEX dupidx (field);
ALTER TABLE table ENGINE InnoDB;
可以帮助
答案 8 :(得分：1)
我知道这是一个古老的话题，但提到的解决方案都没有为我工作。我做了其他有用的事情：
你需要：
答案 9 :(得分：1)
尝试在查询中使用限制。这是因为@Monsters X所说的全盘。
我也遇到了这个问题，并通过查询限制解决了，因为有数千条记录。现在工作得很好:)）
答案 10 :(得分：0)
尝试为查询中涉及的每个表运行修复命令。
使用MySQL管理员，转到目录 - ＆gt;选择您的目录 - ＆gt;选择一个表格 - ＆gt;单击维护按钮 - ＆gt;修复 - ＆gt;使用FRM。
答案 11 :(得分：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上的相同查询没有错误。
答案 12 :(得分：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＆GT;维修台f_scraper_banner_details;
这对我有用
答案 13 :(得分：0)
我的问题来自一个糟糕的查询。我引用了FROM中没有引用的表。
示例：
SELECT t.*,s.ticket_status as `ticket_status`
FROM tickets_new t, ticket_status s, users u
, users u是导致我这个问题的原因。删除它解决了这个问题。
作为参考，这是在CodeIgniter开发环境中。
答案 14 :(得分：0)
在减小 ft_min_word_len （全文的最小字长）后，写入表时收到此消息。要解决此问题，请通过修复表来重新创建索引。
答案 15 :(得分：0)
#include <string>
#include <iostream>
#include "boost/spirit/home/x3.hpp"
#include "boost/spirit/include/support_istream_iterator.hpp"
int main(void)
{
std::string input = \
"\"nodes\":{ {\"type\":\"bb\", \"id\" : 123456567, \"label\" : \"0x12023049\"}," \
"{\"type\":\"bb\", \"id\" : 123123123, \"label\" : \"0x01223234\"}," \
"{\"type\":\"ib\", \"id\" : 223092343, \"label\" : \"0x03020343\"}}";
std::istringstream iss(input);
namespace x3 = boost::spirit::x3;
using x3::char_;
using x3::ulong_long;
using x3::lit;
auto q = lit('\"'); /* q => quote */
auto p1 = q >> lit("type") >> q >> lit(':') >> q >> (lit("bb") | lit("ib")) >> q;
auto p2 = q >> lit("id") >> q >> lit(':') >> ulong_long;
auto p3 = q >> lit("label") >> q >> lit(':') >> q >> (+x3::alpha) >> q;
auto node = lit('{') >> p1 >> lit(',') >> p2 >> lit(',') >> p3 >> lit('}');
auto nodes = q >> lit("nodes") >> q >> lit(':') >> lit('{') >> node % lit(',') >> lit('}');
boost::spirit::istream_iterator f(iss >> std::noskipws), l{};
bool b = x3::phrase_parse(f, l, nodes, x3::space);
return 0;
}
通常可以解决问题
答案 16 :(得分：0)
在这里搜索-“＃1034-表'test'的密钥文件不正确；请尝试对其进行修复”
看到这种情况是由于在Mysql 8.0.21中将字符集添加到索引的枚举（可能与其他字段相同）引起的。
let operation = CKFetchDatabaseChangesOperation()
//Set these...
operation.qualityOfService = .userInitiated
operation.queuePriority = .veryHigh
...
解决方案是在更改之前删除索引。
CREATE TABLE `test` (
`enumVal` ENUM( 'val1' ) NOT NULL
) ENGINE = MYISAM;
ALTER TABLE `test` ADD INDEX ( `enumVal` );
ALTER TABLE `test` CHANGE `enumVal` `enumVal` ENUM( 'val1') CHARACTER SET utf8 COLLATE utf8_bin NOT NULL;