我有一个拖延的查询，我不知道为什么。 它看起来很合理，但它却是“永远”运行的（我去吃午餐，然后离开了，20分钟后还没有完成）。
查看“SHOW PROCESSLIST”，我看到我的连接状态为“Copy to tmp table”。
我查看了我的my.cnf，看起来临时文件应该在/ tmp中，但是那里没有任何与MySQL有关的东西（只有两个目录，都是空的）。
为了帮助我诊断什么是错误的，我想我会看看它本来应该复制到的临时文件。 如果它很大，我一定会搞砸一个查询。 如果没有，也许这是一个错误。
但我不知道它在哪里存储它们。 它是一个内存中的“文件”？
我在Ubuntu 9.04 JeOS安装上运行MySQL 5.1.31。
许多临时表可以并将在内存中创build。 一个表是在内存中还是在磁盘上创build，取决于表的大小，结构（是否有BLOB）等等。
我build议你阅读TMP_TABLE_SIZE和MAX_HEAP_TABL \ E_SIZE以了解临时表是如何工作的。
你可以检查输出
mysql> show status like '%tmp%'; 如果您实际上正在创build磁盘表。 但是请注意，实际的临时表文件对于确定是否存在问题几乎没有任何帮助。
您也可以尝试解释您的查询，看看它应该如何执行。
在debian中 – 默认在/ tmp [afair]
每当有疑问就跑
lsof|grep -i mysqld
mysql的临时文件在创build之后被删除 – 它们显示在lsof上，但不在ls中; 他们确实占用磁盘空间，直到文件句柄closures。
这取决于什么样的临时表。 如果它说“复制到临时表”，那么它是一个内存中的副本。 如果它说“复制到磁盘上的临时表”，那么它已经超过了内存临时表的大小，并且正在转储到磁盘。
在后者的情况下，它将被存储在由tmpdirvariables定义的位置。 您可以通过以下方式找出设置的内容：
SHOW VARIABLES LIKE 'tmpdir';
有一个mysqlvariables，指出文件的存储位置：
mysql> show variables like '%tmp%';
寻找tmpdirvariables。 这将告诉你tmp文件的存储位置。 如果临时表小于“tmp_table_size”，它将基于内存而不是基于磁盘。