在MySQL运行一段时间后（通常是4-6小时），一些更大，负载更大的查询永久（直到重新启动）失败，返回以下错误：
Can't create/write to file '#sql_75ed_0.MYD' (Errcode: 17) 谷歌search这个错误返回很多可能的原因，但我觉得这可能是在两个简单的方法可以解决;
1）优化查询。 （从长远来看，这是一个很好的解决scheme。）
2）以某种方式调整MySQLconfiguration。 （这是我想要做的）
鉴于这个问题，这里是我们目前在my.cnf中的非默认值：
query_cache_size = 8M query_cache_limit = 8M thread_cache_size = 4 max_connections = 90 table_cache = 4096 innodb_buffer_pool_size = 900M tmp_table_size = 512M max_heap_table_size = 256M innodb_file_per_table
我倾向于相信，通过进一步调整这些variables，我们可能注意到显着的性能增益，但这是一个待解决的问题。
以下是一个开始失败的示例查询：
SELECT DISTINCT u.user_id, u.username, u.username_clean, u.user_colour, MAX(s.session_time) as online_time, MIN(s.session_viewonline) AS viewonline FROM (table_users u, table_zebra z) LEFT JOIN table_sessions s ON (s.session_user_id = z.zebra_id) WHERE z.user_id = 4 AND z.friend = 1 AND u.user_id = z.zebra_id GROUP BY z.zebra_id, u.user_id, u.username_clean, u.user_colour, u.username ORDER BY u.username_clean ASC
上述查询的EXPLAIN结果返回如下内容：
1, 'SIMPLE', 'z', 'ref', 'PRIMARY,zebra_id_friend', 'PRIMARY', '3', 'const', 18, 'Using where; Using temporary; Using filesort' 1, 'SIMPLE', 's', 'ref', 'session_user_id', 'session_user_id', '3', 'database_name.z.zebra_id', 402, '' 1, 'SIMPLE', 'u', 'eq_ref', 'PRIMARY', 'PRIMARY', '3', 'database_name.z.zebra_id', 1, ''
任何援助将不胜感激！
这是相当晦涩的，但我认为你可能会（只是可能）有一堆死的SQL临时表像悬挂在一起，最终mysqld试图重用相同的文件名，并失败，因为它有内部规则告诉它永远不会覆盖一个.MYD 。
我build议的是看看这些#sql_XXXX_X.MYD文件在哪里，closuresmysqld，清除临时文件并重新启动它。
如果这实际上是这样的话，优化你的查询似乎会有所帮助，如果你能得到它，以便它不创build临时表，但除非你清理死的文件，好处将是虚幻的。 尽pipe如此，优化查询让你不太可能在将来遇到临时表是一个好主意。
MySQL在某些情况下创build临时文件来处理查询结果。 发生这种情况的一种常见情况是在文本或Blobtypes的列数据上进行sorting时。 其他包括当最大允许临时表大小用尽。
这些表的创build表明可能没有完全优化的查询，但在某些情况下，这些查询是无法避免的。 但是，您不应该收到错误（在我使用的某些生产环境中，可能会每分钟创build几十个）。
通常这些文件是在/ tmp中创build的。 你可以看这个目录，看看它们被创build和销毁。 如果/ tmp，或者正在使用哪个目录，都不能被mysql用户写入，这可能是你的问题。
否则，寻找更多的世俗问题，如磁盘空间不足。
以下是来自MySQL文档的一些附加信息。