我从 MySQL 查询中得到以下错误。
#126 - Incorrect key file for table
我什至没有为这个表声明一个键，但我确实有索引。有谁知道可能是什么问题？
问问题
139695 次
17 回答
167
每次发生这种情况，根据我的经验，它都是一个完整的磁盘。
编辑
还值得注意的是，如果您配置了 ramdisk，则在执行诸如更改大表之类的操作时，这可能是由于 ramdisk 已满引起的。如果您不能增加它的大小，您可以暂时注释掉 ramdisk 行以允许此类操作。
于 2011-12-08T16:48:27.453 回答
35
首先，您应该知道键和索引在 MySQL 中是同义词。如果您查看有关CREATE TABLE Syntax的文档，您可以阅读：
KEY通常是 的同义词INDEX。PRIMARY KEY也可以KEY在列定义中指定key 属性。这是为了与其他数据库系统兼容而实现的。
现在，您遇到的错误可能是由于两件事：
- MySQL 服务器上的磁盘问题
- 损坏的键/表
在第一种情况下，您将看到为查询添加限制可能会暂时解决问题。如果这样做对您有用，那么您可能有一个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。
于 2013-12-09T10:13:43.183 回答
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。
于 2012-09-06T15:18:14.540 回答
10
错误 #126 通常发生在您的表损坏时。解决此问题的最佳方法是进行修复。这篇文章可能会有所帮助：
于 2010-01-06T05:13:22.033 回答
3
ft_min_word_len = 2设置时出现此错误my.cnf，它将全文索引中的最小字长从默认值 4 降低到 2。
修理桌子解决了这个问题。
于 2014-08-14T16:46:26.103 回答
2
我知道这是一个老话题，但提到的解决方案都不适合我。我做了其他有效的事情：
你需要：
- 停止 MySQL 服务：
- 打开 mysql\数据
- 删除 ib_logfile0 和 ib_logfile1。
- 重启服务
于 2014-08-22T10:20:33.590 回答
1
我解决了这个问题：
ALTER TABLE table ENGINE MyISAM;
ALTER IGNORE TABLE table ADD UNIQUE INDEX dupidx (field);
ALTER TABLE table ENGINE InnoDB;
可能会有所帮助
于 2014-11-14T16:22:56.460 回答
1
尝试在查询中使用限制。这是因为@Monsters X 所说的完整磁盘。
我也遇到过这个问题并通过查询限制解决，因为那里有数千条记录。现在工作得很好:)
于 2013-02-15T06:45:26.357 回答
1
repair table myschema.mytable;
于 2014-09-12T10:19:23.027 回答
1
转到/etc/mysql/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
于 2015-06-30T21:17:05.510 回答
1
现在其他答案为我解决了。事实证明，在同一查询中重命名列和索引会导致错误。
不工作：
-- 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 上的相同查询没有错误。
于 2016-04-05T15:24:17.643 回答
0
尝试为查询中涉及的每个表运行修复命令。
使用 MySQL 管理员，转到目录 -> 选择目录 -> 选择表 -> 单击维护按钮 -> 修复 -> 使用 FRM。
于 2012-04-09T00:13:07.357 回答
0
我的问题来自一个错误的查询。我在 FROM 中引用了一个表，而在 SELECT 中没有引用。
例子：
SELECT t.*,s.ticket_status as `ticket_status`
FROM tickets_new t, ticket_status s, users u
, users u是什么导致了我的问题。删除它解决了这个问题。
作为参考，这是在 CodeIgniter 开发环境中。
于 2016-08-12T17:40:56.823 回答
0
我在减少ft_min_word_len（全文最小字长）后写入表时收到此消息。要解决它，请通过修复表重新创建索引。
于 2020-03-25T12:39:46.453 回答
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> repair table f_scraper_banner_details;
这对我有用
于 2016-07-01T07:21:15.190 回答
0
mysqlcheck -r -f -uroot -p --use_frm db_name
通常会做的伎俩
于 2020-07-24T20:05:08.413 回答
0
来到这里搜索 - “#1034 - 表 'test' 的密钥文件不正确；尝试修复它”
看到这是由使用 Mysql 8.0.21 向索引枚举（可能与其他字段相同）添加字符集引起的。
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;
使用的解决方案是在更改之前删除索引。
ALTER TABLE `test` ADD INDEX ( `enumVal` );
于 2020-09-28T19:01:47.133 回答