MySQL REPAIR TABLE 由于空间问题而停滞

我大约 4 天前开始了一个维修表:
Query | 351804 | Repair by sorting | REPAIR TABLE
它使用了磁盘上的所有空间:
/dev/md0 9.2G 8.8G 0 100% /
一旦我删除了一些东西，空间就会很快用完。我现在可以删除的东西已经用完了。另外，我无法弄清楚所有空间都去了哪里:

dispus v2.4 - Reading usage in /
Ignoring mount points: proc sys home

9,133,044 KB used of 9,621,752 KB available (100%)

1.  1,859,308 KB   usr
2.  1,142,836 KB   var
3.    274,692 KB   lib
4.     35,924 KB   root
5.     25,308 KB   boot
6.     19,756 KB   sbin
7.     18,400 KB   lib64
8.     15,936 KB   etc
9.      6,732 KB   bin
etc

mysql 数据目录位于不同的分区上。

任何人都知道如何完成此修复？

* 更新**

lsof | grep deleted
mysqld    20862    mysql  189u      REG                9,0  4724886042      81629 /tmp/STqCaElP (deleted)
mysqld    20862    mysql  201u      REG                9,0  1107226624      81633 /tmp/STWfcUNu (deleted)

似乎是问题所在。现在要弄清楚该怎么做。我不愿意终止维修查询，但可能不得不......

最佳答案

http://dev.mysql.com/doc/refman/5.5/en/kill.html 说:



所以你可以杀死它，但你必须再次运行修复，并且存在无法修复的风险。如果发生这种情况，您必须从最近的备份中恢复，并且您可以尝试使用二进制日志执行 point-in-time recovery。
REPAIR TABLE 操作需要大约两倍于它试图修复的表的磁盘空间。
REPAIR TABLE 在配置变量 tmpdir 定义的位置使用临时存储。确保在启动 REPAIR TABLE 之前将此变量更改为有足够磁盘空间的分区。 Tmpdir 不是动态变量，因此您必须重新启动 mysqld 才能更改它。

看到这个类似的问题:https://dba.stackexchange.com/questions/11352/repairing-myisam-table-when-there-was-no-additional-disk-space-table-corrupted

另一条建议:考虑 using InnoDB instead of MyISAM.

关于MySQL REPAIR TABLE 由于空间问题而停滞，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/14442780/