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

则会触发错误。这仅发生在我当前使用的特定网络服务器上。如果我下载数据库并在本地主机和其他服务器上尝试相同的操作，它运行良好。 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 以便其分区有更多空间（通过重新分配或将其移动到主分区 - 例如 参见此处)
(b) 更改 MySql 配置，使其使用 不同的临时文件夹< /a> 位于不同的分区，例如 /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”以保持所有表统计信息最新。

Answer 5

我在对包含 500K+ 条记录的表进行查询时遇到了这个问题。
它给了我同样类型的错误，指向 /tmp 目录中的 .MYI 文件，但在检查时很少出现该文件。我已经增加了 /etc/my.cnf 文件中的堆和临时文件大小。

该查询的问题是它确实在末尾包含一个 ORDER 子句，省略它会使查询正常工作而不会出现错误。它也有一个限制。我试图查看表中最近的 5 条记录。当包含 ORDER 子句时，它会卡住并给出错误。

发生的情况是 mysqld 正在创建一个内部临时表，其中包含巨型表中的所有记录来应用订单。

我解决这个问题的方法是应用一个额外的 WHERE 条件，将巨型表中的记录限制为一些较小的集合。我方便地有一个日期时间字段来进行过滤。

我希望这对某人有帮助。

Answer 6

在 Unix 上，MySQL 使用 TMPDIR 环境变量的值作为存储临时文件的目录的路径名。如果未设置TMPDIR，MySQL将使用系统默认值，通常是/tmp、/var/tmp或/usr/tmp。

在 Windows、Netware 和 OS2 上，MySQL 按顺序检查 TMPDIR、TEMP 和 TMP 环境变量的值。对于第一个被发现设置的，MySQL 使用它并且不检查剩余的那些。如果没有设置TMPDIR、TEMP或TMP，MySQL将使用Windows系统默认值，通常是C:\windows\temp。

如果包含临时文件目录的文件系统太小，您可以使用 mysqld 的 --tmpdir 选项来指定文件系统中具有足够空间的目录。

在 MySQL 5.0 中，--tmpdir 选项可以设置为以循环方式使用的多个路径的列表。在 Unix 上，路径应以冒号 (“:”) 分隔；在 Windows、NetWare 和 OS/2 上，路径应以分号 (“;”) 分隔。

Answer 7

我遇到同样的问题。

这是我的解决方案：
1. 不要使用“选择*”。只需选择您需要的字段。
2. 拆分查询。如果您选择的字段太多，则将其拆分为某个查询可能会是一个结果。如果您希望包含结果的变量不发生更改，您可以稍后使用“array_merge()”结果。

就我而言，我将查询拆分为 5 个查询，然后使用 PHP 对其进行数组合并。

问题出在mysql服务器上。这只是应用程序开发人员（例如我们）没有特权。

Answer 8

只增加文件tmp，因为mysql没有空间，用于查询...

mount -o remount,size=[NEW MAX SIZE HERE] tmpfs /tmp

链接参考：

一般错误：126 表 '/tmp/#sql_254c_0.MYI' 的密钥文件不正确；尝试修复它

[错误] /usr/sbin/mysqld: 表 '/mysqltmp/#sql_ca1a_0.MYI' 的密钥文件不正确；尝试修复它

如何增加 /tmp 分区大小

Answer 9

我有类似的问题。就我自己而言，问题是由于不正确的所有者/权限而发生的。我只需将数据目录的所有者更改为 mysql 用户即可解决问题。

Answer 10

3 个表之一的索引键可能损坏，请尝试对所有 3 个表运行修复命令。

Answer 11

使用 EXPLAIN 关键字可能有助于找出如何最好地优化此查询。本质上，您需要做的是尽快获得尽可能小的结果集。如果您在 core_username 中的每一行直到最后都有一个结果集，那么当您订购它时，您将面临...这个风险。

如果您可以单独对 core_username 进行排序而不会出现问题，则您可能希望将 min() 行作为子查询获取。