Mysql tmp_table_size max_heap_table_size

Question

我的服务器2天前我的tmp_table_size = max_heap_table_size(16M)。

我创建了一个每小时运行一次的cron作业，并从以下项开始生成报告：created_tmp_disk_tables，created_tmp_files，created_tmp_tables

在我的报告中：created_tmp_disk_tables + created_tmp_files + created_tmp_tables =我的临时数据的100％

有了这个：

1. tmp_table_size = max_heap_table_size = 16M报告向我展示了下一份平均报告：
   • 27.37％（created_tmp_disk_tables）
   • 1.16％（created_tmp_files）
   • 71.48％（created_tmp_tables）

如何优化这些结果？

1. 在第一个小时内tmp_table_size = max_heap_table_size = 20M：

   • 23.48％（created_tmp_disk_tables）
   • 32.44％（created_tmp_files）
   • 44.07％（created_tmp_tables）

7小时后（重启后）：

• 21.70％（created_tmp_disk_tables）
• 33.75％（created_tmp_files）
• 44.55％（created_tmp_tables）

这不是我的预期。

• 磁盘表从27.37%减少到21.70% - ＆gt;预期更多
• 临时文件从1.16%上升到33.75% - ＆gt;为什么？
• 内存表从71.48%减少到44.55% - ＆gt;奇怪;预计会上升

Answer 1

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

当查询在没有索引的情况下执行连接或排序（通过ORDER BY）时，必须在内存中形成临时表。这会增加Created_tmp_tables。

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

1. 查询处理必须停止
2. 在磁盘上创建临时表
3. 将基于内存的临时表的内容传输到基于磁盘的临时表
4. 放入基于内存的临时表
5. 使用基于磁盘的临时表继续查询处理

此过程会增加Created_tmp_disk_tables

了解这些机制，让我们探讨每个实例中发生的事情

  

磁盘表从27.37％下降到21.70％ - ＆gt;期待更多

如果之前运行的查询已将缓存结果保留在RAM中，则很容易发生这种情况。这将消除从头开始处理查询的需要，而不是重新创建相同的大临时表。

  

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

这并不奇怪。这简单地说明了存在需要临时表的查询的事实。它们首先在RAM中创建。这只表示存在未加入的查询（可能join_buffer_size太小）或ORDER BY非索引列或具有临时表的列（可能sort_buffer_size太小）

  

内存表从71.48％下降到44.55％ - ＆gt;奇怪;预计会上升

这也不奇怪。如果对具有相同值的相同查询有足够的调用，则可以通过从先前缓存的结果中完成查询来抢占排序和连接。

建议

根据这些事情，可以调整的是：

• join_buffer_size
• sort_buffer_size
• 创建将使用的索引
  通过eq_ref 加入
  • 按顺序通过索引扫描排序

总体目标应该是尽可能地防止创建临时表。简单地增加tmp_table_size和max_heap_table_size就会让缺乏正确索引的低效查询和表格陷入困境。