在进行多个连接时,MySQL不正确的tmp表密钥文件

Question

我不经常来这里寻求帮助,但我对此非常沮丧,我希望有人以前遇到过它.

每当我尝试使用多个连接从表中获取记录时,我都会收到此错误:

#126 - Incorrect key file for table '/tmp/#sql_64d_0.MYI'; try to repair it

所以这个查询会产生错误:

SELECT * FROM `core_username`
INNER JOIN `core_person` ON (`core_username`.`person_id` = `core_person`.`id`)
INNER JOIN `core_site` ON (`core_username`.`site_id` = `core_site`.`id`)
ORDER BY `core_username`.`name` ASC LIMIT 1

但是这个不会:

SELECT * FROM `core_username`
INNER JOIN `core_person` ON (`core_username`.`person_id` = `core_person`.`id`)
ORDER BY `core_username`.`name` ASC LIMIT 1

这一个也不会:

SELECT * FROM `core_username`
INNER JOIN `core_site` ON (`core_username`.`site_id` = `core_site`.`id`)
ORDER BY `core_username`.`name` ASC LIMIT 1

可能是什么导致了这个？我真的不知道如何修复tmp表,但我不认为这是问题,因为它每次都是一个新的tmp表.用户名表相当大(现在有233,718条记录),但我怀疑它与它有什么关系.

任何帮助将非常感激.

更新:经过一些进一步的测试后,似乎错误只发生在我尝试订购结果时.也就是说,这个查询会给我我的期望:

SELECT * FROM `core_username`
INNER JOIN `core_person` ON (`core_username`.`person_id` = `core_person`.`id`)
INNER JOIN `core_site` ON (`core_username`.`site_id` = `core_site`.`id`)
LIMIT 1

但如果我添加:

ORDER BY `core_username`.`name` ASC

错误被触发.这只发生在我目前使用的特定网络服务器上.如果我下载数据库并在我的localhost以及其他服务器上尝试相同的操作,它运行正常.MySQL版本是5.0.77.

知道了这一点我相信发生的事情就是创建的tmp表太大了,而且这个博客文章中描述了 MySQL的窒息.我仍然不确定解决方案是什么,但......

Answer 1

有时当临时表发生此错误时:

#126 - Incorrect key file for table '/tmp/#sql_64d_0.MYI'; try to repair it

可能是因为/tmp文件夹空间不足.在某些Linux安装,/tmp是在自己的分区,并没有什么太大的空间-大MySQL的查询将它填平.

您可以使用它df -h来检查是否\tmp在它自己的分区中,以及分配了多少空间.

如果它在自己的分区中并且空间不足,您可以:

(a)修改/ tmp以使其parition有更多的空间(通过重新分配或将其移动到主分区 - 例如,见这里)
(b)更改MySql配置,以便它在不同的分区上使用不同的临时文件夹,例如/var/tmp

Answer 2

在运行查询时检查你的MySQL tmpdir可用空间(在你的情况下是/ tmp),因为在使用大表时它可能会吃掉数百MB.这样的事情对我有用:

$ while true; do df -h /tmp; sleep .5; done

Answer 3

跑这个

REPAIR TABLE `core_username`,`core_site`,`core_person`;

或者这样做:

select * from (
 SELECT * FROM `core_username`
 INNER JOIN `core_person` ON (`core_username`.`person_id` = `core_person`.`id`)
 INNER JOIN `core_site` ON (`core_username`.`site_id` = `core_site`.`id`)
 LIMIT 1)
ORDER BY `name` ASC

Answer 4

您可能会发现运行“ANALYZE TABLE”有帮助。

我们在一个大表（~100M行）上突然出现这个问题，MySQL尝试使用/tmp写入超过1GB的临时表，但由于/tmp限制为~600M而失败。

事实证明，InnoDB 表的统计信息相当陈旧。运行“ANALYZE TABLE ...”后，统计数据已更新，问题已解决。有了更准确的统计数据，MySQL 能够正确优化查询，不再需要大的 tmp 文件。

我们现在定期运行“mysqlcheck -Aa”以保持所有表统计信息最新。