mysql maxtmptables_mysql tmp_table_size max_heap_table_siz

每当您增加tmp_table_size和max_heap_table_size时，请记住，设置这些值不会使查询表现得更好。 实际上，它使低效率的查询的行为比以前更糟。 什么情况下

当查询执行连接或排序(通过ORDER BY)而没有索引的好处时，必须在内存中形成临时表。 这将增加Created_tmp_tables。

如果临时表增长到tmp_table_size中的字节数并且需要更多空间怎么办？ 发生以下事件序列：

查询处理必须停止

在磁盘上创建一个临时表

将基于内存的临时表的内容传输到基于磁盘的临时表中

放入基于内存的临时表

查询处理继续使用基于磁盘的临时表

此过程增加Created_tmp_disk_tables

了解了这些机制，让我们探讨一下每种情况下发生的情况

磁盘表从27.37％下降到21.70％->预期更多

如果之前运行的查询将结果缓存在RAM中，则很容易发生这种情况。 这样就无需从头开始处理查询，而无需重新创建相同的大型临时表。

临时文件从1.16％上升到33.75％->为什么？

这不足为奇。 这仅表明存在需要临时表的查询这一事实。 它们首先在RAM中创建。 这仅表示存在无法很好连接的查询(可能是join_buffer_size太小)或ORDER BY非索引列或具有临时表的列(可能是sort_buffer_size太小)。

内存表从71.48％下降到44.55％->奇怪； 预计会上升

这也不足为奇。 如果对于具有相同值的同一查询有足够的调用，则可以通过执行先前缓存的结果来抢占排序和联接。

建议

鉴于这些情况，可以进行以下调整：

join_buffer_size

sort_buffer_size

创建将要使用的索引通过eq_ref加入

通过索引扫描排序

总体目标应该是尽可能避免创建临时表。 简单地增加tmp_table_size和max_heap_table_size可以使效率低下的查询和缺少正确索引的表正常运行。