MySQL 的密钥文件不正确答案

【问题标题】：Incorrect key file with MySQLMySQL 的密钥文件不正确
【发布时间】：2011-04-23 22:06:11
【问题描述】：

我在使用 InnoDB（表最初是 MyISAM，但不久前将其转换为 InndoB）表时遇到问题；我正在尝试运行此查询：

SELECT 
   posts.id,
   posts.post_title
FROM
   rss_posts AS posts
   INNER JOIN rss_feeds AS feeds ON posts.blog_id=feeds.id
WHERE
   feeds.blog_language=1
ORDER BY
   posts.post_date_db DESC
LIMIT
   10;

我收到此错误：

Query : SELECT   posts.id,posts.post_title  FROM   rss_posts AS posts   INNER JOIN vw_rss_feeds AS feeds ON posts.blog_id=feeds.id  WHER...
Error Code : 126
Incorrect key file for table '/tmp/#sql_7375_0.MYI'; try to repair it

我无法对涉及的表进行修复；但是我对两张桌子都进行了检查，它们看起来都很好。我还对两个表进行了优化，并且还通过执行以下操作重建了表..

INSERT INTO new_table SELECT * FROM old_table;

然后我将新表重命名为旧表名......但我仍然遇到这个问题。

为了尝试找出导致它的表，我删除了查询中引用“rss_feeds”表的代码......所以现在查询看起来像这样......

SELECT 
   posts.id,
   posts.post_title
FROM
   rss_posts AS posts
ORDER BY
   posts.post_date_db DESC
LIMIT
   10;

成功了。

所以问题出在 rss_feeds 表上。

然后我想我会将表转换回 MyISAM 并运行修复然后转换回 InnoDB ......这暂时工作，它恢复正常......然后它又坏了...... .. 又修了，又坏了.. 现在修复似乎根本不起作用。

现在，我知道，我知道......我已经在谷歌上搜索过这个问题......我注意到问题的大部分时间是我们在 MySQL 中没有足够的空间临时目录....但是我已经让主机将临时目录更改为具有更多空间的东西，问题仍然存在。

我认为应该归咎于主机，但它仍然是临时目录的问题；为什么？因为在我让它再次工作后，我开始再次向 rss_posts 表添加数据，因此 JOIN 会变得更大，而 MySQL 会再次耗尽空间......你觉得呢？

【问题讨论】：

标签： mysql innodb mysql-error-126

【解决方案1】：

这里发生的事情是 MySQL 通过从两个表的连接中构建一个临时表来执行 ORDER BY。临时表太大而无法放入内存，因此 MySQL 创建了一个临时文件。

有一些事情会阻止它正常工作。原始磁盘空间就是其中之一。 ulimit 是另一个。如果这是托管的，他们可能对您的磁盘使用有配额（除了 ulimit）。

我建议在您的查询中添加限制子句。当前，您将整个 rss_posts 和 rss_feeds 加载到临时表中进行排序。如果您只想要最近的 10 个数据，那么这比您真正需要的数据要多得多。

SELECT posts.id, posts.post_title 
FROM rss_posts AS posts INNER JOIN rss_feeds AS feeds ON posts.blog_id=feeds.id 
WHERE feeds.blog_language=1 
AND posts.post_data_db > (now - interval 30 day);
ORDER BY posts.post_date_db DESC LIMIT 10;

【讨论】：

谢谢 - 肯定有足够的可用磁盘空间；基本上楼主是这么说的。。“'/var/tmp'分区使用和'/'一样的空间，目前它的使用信息如下；/dev/sda3 442G 130G 289G 32% / 所以你应该看不到空间有任何问题。”虽然我想知道 /var/tmp/ 目录本身是否受到限制？如果这甚至可能的话。所以你在那里的那个查询 - 基本上只得到过去 30 天的最后 10 个帖子？
正确。您可以将“30”参数化以使其更广泛。但是，如果您不断地将整个两个表排序为 10 行，那么无论可用磁盘空间如何，您都会遇到扩展和性能问题。
好的.....好吧，我已将查询更改为您建议的内容（甚至尝试了 1 天），但错误仍然存在......它确实工作了一段时间，但随后出现错误回来。 :(
每天有多少行进入 RSS_POSTS 表？ rss_posts.post_date_db 列的数据类型是什么？我可能弄错了我的日期算术，需要一个更好的值。阅读 ulimit 命令，该命令可以限制每个进程或每个用户使用的磁盘空间，并专门向您的主机询问结果。
目前大约 500k... 但这个数字以后应该会显着增加。 rss_posts.post_date_db 列是一个 bigint。在我进行搜索之前，我在 ulimit 上找不到太多好的信息.....我假设它是服务器的事情而不是 MySQL 正确的？

【解决方案2】：

看起来您用于临时表的磁盘配额太小了。

顺便说一句：不需要在 InnoDB 表上运行 REPAIR，因为所有维护都由存储引擎本身完成。他们也没有要损坏的密钥文件。

【讨论】：

【解决方案3】：

注意 .MYI 文件有问题的是临时表。当您运行涉及连接的查询时，MySql 需要使用临时空间在内部合并数据。您的 tmp 目录中的空间很可能已用完。

尝试增加分配给 tmpdir 的空间量或编辑 my.cnf 文件以使 tmpdir 指向具有足够空间的位置（不要忘记授予它权限）。

【讨论】：