56

两天前在我的服务器上我的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%-> 预期更多
  • 临时文件上升1.16%到33.75% -> 为什么？
  • 内存表从减少71.48%到44.55%-> 奇怪；预计会上涨
4

1 回答 1

192

每当您增加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% -> 预期更多

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

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

这并不奇怪。这只是表明存在需要临时表的查询。它们首先在 RAM 中创建。这只是表示存在连接不好的查询（可能join_buffer_size太小）或ORDER BY临时表的非索引列或列（可能sort_buffer_size太小）。

内存表从 71.48% 降低到 44.55% -> 奇怪；预计会上涨

这也不足为奇。如果对具有相同值的相同查询有足够多的调用，则排序和连接可能会被先前缓存结果中的查询的执行抢占。

推荐

鉴于这些事情，这里是可以调整的：

总体目标应该是尽可能地防止创建临时表。简单地增加tmp_table_size和max_heap_table_size会让效率低下的查询和缺乏正确索引的表异常运行。

于 2013-02-01T18:06:29.693 回答