为什么MySQL在磁盘上创建了这么多临时表？

任何配置错误都能导致mysql..mysql调谐器显示创建过多的临时表吗

Current max_heap_table_size = 200 M
Current tmp_table_size = 200 M
Of 17158 temp tables, 30% were created on disk

table_open_cache = 125 tables
table_definition_cache = 256 tables
You have a total of 97 tables
You have 125 open tables.
Current table_cache hit rate is 3%

较早的临时表是“在23725个临时表中，有38％是在磁盘上创建的”，但我将max_heap和tmp_table从16m更改为200m，并将其降低到30％。

组态：

engine myisam 
group_concat_max_len = 32768
key_buffer_size = 3.7 GB,
thread_stack = 256k,
table_cache = 125
query_cache_limit = 1M
query_cache_size = 16M
join_buffer_size = 2.00 M
max_connections = 800

另一个具有默认配置的系统显示带有相同数据库的“ 23725个临时表，其中1％是在磁盘上创建的”。

我尝试将计算机上的默认设置更改为此问题，它仍然显示“在580个临时表中，有16％是在磁盘上创建的”。

我正在使用带有48 GB RAM的Ubuntu 11.4 64位。有人可以提出解决方案吗？

使用“ group by”将表上的数据库引擎从“ myisam”更改为“ memory”是否可以解决此问题？如此处所述：http : //www.mysqlperformanceblog.com/2007/08/16/how-much-overhead-is-caused-by-on-disk-temporary-tables/

mysqltuner很少提供任何有用的信息。它使用有关“命中率”的最不相关的统计信息，并对可接受的小部件数量进行任意限制。如果您没有遇到性能问题，那么您实际上不需要解决它所带来的任何问题。话虽如此，这是有关临时表的一些背景信息...

MySQL内部使用MEMORY存储引擎创建隐式临时表。在磁盘临时表上，使用MyISAM存储引擎。

在以下情况下，将在磁盘上创建临时表：

• 存在TEXT或BLOB字段（因为MEMORY不支持这些类型）
• 结果隐式临时表的大小超过tmp_table_size或max_heap_table_size
• 如果将超过512个字节的列与GROUP BY或UNION或ORDER BY一起使用

请阅读内部临时表上的MySQL文档以获取更多详细信息。

您能对此做什么？假定它实际上代表一个性能问题（而不只是直觉上打扰您）：

• 避免使用TEXT / BLOB字段，而尽可能使用大小适当的VARCHAR或CHAR字段。
• 如果TEXT / BLOB是不可避免的，则将它们隔离到具有外键关系的单独表中，并仅在需要时才进行JOIN。
• 与上述TEXT / BLOB字段一样，处理大于512字节的大列。
• 确保查询仅返回所需的结果集（适当的选择性WHERE子句，避免使用SELECT *）
• 避免使用子查询，并用联接替换它们，尤其是当它们返回较大的结果集时
• 最后一招-提高两个tmp_table_size和max_heap_table_size。除非您发现无法优化查询，否则请不要这样做。

如果您担心MySQL的配置，而自己又对可用的设置不满意，则可能需要以Percona配置向导为起点。

使用“ group by”将表上的数据库引擎从“ myisam”更改为“ memory”是否可以解决此问题？如这里解释

不，它不会，它将使您的表永不持久化到磁盘。不要这样

“使用临时文件”和“使用文件排序”并不是世界末日！

SELECT ... GROUP BY a，b ORDER BY c，d-需要1或2个“临时表”。

有时候您的查询将使用临时表。临时表可能会使查询速度降低一小部分。但是，如果查询仍然“足够快”，则不必担心。

如果查询太慢（有或没有tmp表），让我们讨论一下。请提供SHOW CREATE TABLE，SHOW TABLE STATUS和EXPLAIN。