【问题标题】:MySQL: #126 - Incorrect key file for tableMySQL:#126 - 表的密钥文件不正确
【发布时间】:2011-01-01 22:26:03
【问题描述】:

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

#126 - Incorrect key file for table

我什至没有为这个表声明一个键,但我确实有索引。有谁知道可能是什么问题?

【问题讨论】:

  • 我也得到了这个视图
  • tmp文件夹一般有2GB的限制,试试df -h看看
  • 如果你已经完成了REPAIR TABLE 并且仍然得到这个,加上/tmp 上有空间,那么你可能想尝试重新启动服务器。

标签: mysql mysql-error-126


【解决方案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

【讨论】:

    【解决方案2】:
    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;
    

    这对我有用

    【讨论】:

      【解决方案3】:
      mysqlcheck -r -f  -uroot -p   --use_frm db_name
      

      通常会成功

      【讨论】:

      • 你能解释一下原因吗?
      【解决方案4】:

      来这里搜索 - “#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之前删除索引。

      ALTER TABLE `test` ADD INDEX ( `enumVal` );
      

      【讨论】:

        【解决方案5】:

        我在减少 ft_min_word_len(全文最小字长)后写入表时收到此消息。为了解决这个问题,通过修复表重新创建索引。

        【讨论】:

          【解决方案6】:

          我的问题来自一个错误的查询。我在 FROM 中引用了一个表,在 SELECT 中没有引用。

          示例:

             SELECT t.*,s.ticket_status as `ticket_status`
             FROM tickets_new t, ticket_status s, users u
          

          , users u 是造成我问题的原因。删除它解决了这个问题。

          作为参考,这是在 CodeIgniter 开发环境中。

          【讨论】:

            【解决方案7】:

            现在其他答案为我解决了。事实证明,在同一查询中重命名列和索引会导致错误。

            不工作:

            -- 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 上的相同查询没有错误。

            【讨论】:

              【解决方案8】:

              按照这些说明,我可以重新创建我的 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。

              【讨论】:

                【解决方案9】:

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

                编辑

                还值得注意的是,如果您配置了 ramdisk,则在执行诸如更改大表之类的操作时,这可能是由 ramdisk 已满引起的。如果您无法增加它的大小,您可以暂时注释掉 ramdisk 行以允许此类操作。

                【讨论】:

                • 我还有大约 2Gb 的可用空间并收到此错误。但是我的数据库大约 1.7 Gb,并且数据库有一个大约 150 万行的表。清理后,当可用空间大约 3.5-4Gb 时,错误消失。
                • 在我的系统上(Fedora 18)/tmp 是一个小的 tmpfs 文件系统,mysql 用尽了空间来写一个临时表。我必须设置 tmpdir 配置变量,如 mysql.com 中所述
                • 虽然这可能是一个原因,但这对我来说从来都不是因为磁盘满了。我在分配给 10GB 的 Amazon RDS 实例上遇到此错误,该实例只有 1% 已满。内存不足也可能是一个原因。
                • 您可以在 my.cnf 中设置 tmpdir=/mysql_tmp 或其他内容,它应该在根文件系统上(不管它有多大)
                • 我也有同样的错误,虽然我有磁盘空间 [root@ADM-PROD-PERCONA-SL-RP-03 percona]# df -h Filesystem Size Used Avail Use% Mounted on /dev/xvda1 7.8G 1.6G 6.1G 21% / devtmpfs 61G 80K 61G 1% /dev tmpfs 61G 0 61G 0% /dev/shm /dev/md0 3.0T 1.8T 1.2T 61% /mnt
                【解决方案10】:

                我解决了这个问题:

                ALTER TABLE table ENGINE MyISAM;
                ALTER IGNORE TABLE table ADD UNIQUE INDEX dupidx (field);
                ALTER TABLE table ENGINE InnoDB;
                

                可能会有所帮助

                【讨论】:

                • 我只用一步就能解决类似的问题,您可以使用当前的表引擎重建表。即,如果您使用 myisam,请使用:ALTER IGNORE TABLE table ENGINE=MyISAM;
                【解决方案11】:
                repair table myschema.mytable;
                

                【讨论】:

                  【解决方案12】:

                  我知道这是一个老话题,但提到的解决方案都不适合我。我做了一些其他的工作:

                  你需要:

                  1. 停止 MySQL 服务:
                  2. 打开mysql\data
                  3. 同时删除 ib_logfile0 和 ib_logfile1。
                  4. 重启服务

                  【讨论】:

                    【解决方案13】:

                    我在my.cnf 中设置ft_min_word_len = 2 时出现此错误,这会将全文索引中的最小字长从默认的4 降低到2。

                    修复表解决了问题。

                    【讨论】:

                    • 你知道这只是在你第一次更改设置时才会发生,还是因为最小字长太小而可能发生的事情?
                    【解决方案14】:

                    首先,您应该知道键和索引在 MySQL 中是同义词。如果您查看有关CREATE TABLE Syntax 的文档,您可以阅读:

                    KEY 通常是 INDEX 的同义词。当在列定义中给出键属性 PRIMARY 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

                    【讨论】:

                      【解决方案15】:

                      尝试在查询中使用限制。这是因为@Monsters X 所说的完整磁盘。

                      我也遇到过这个问题并通过查询限制解决,因为那里有数千条记录。现在工作得很好:)

                      【讨论】:

                        【解决方案16】:

                        尝试为查询中涉及的每个表运行修复命令。

                        使用 MySQL 管理员,进入目录 -> 选择目录 -> 选择表 -> 点击维护按钮 -> 修复 -> 使用 FRM。

                        【讨论】:

                          【解决方案17】:

                          错误 #126 通常发生在您的表损坏时。解决此问题的最佳方法是进行修复。 这篇文章可能会有所帮助:

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

                          【讨论】:

                          • 我删除了所有密钥并进行了优化。如果我的查询太慢,我会收到这个错误吗?
                          • 我不确定,但根据我的理解,这个错误不是由查询引起的。你试过修理了吗?
                          猜你喜欢
                          • 2013-09-30
                          • 2016-01-27
                          • 2012-11-08
                          • 1970-01-01
                          • 2011-04-23
                          • 1970-01-01
                          • 1970-01-01
                          • 1970-01-01
                          • 1970-01-01
                          相关资源
                          最近更新 更多