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%
接着就,随即 :
tmp_table_size= max_heap_table_size= 16M报告向我显示下一个平均报告:
如何优化这些结果？
与tmp_table_size= max_heap_table_size= 20M在第一个小时:
7小时后(重启后):
这不是我的预期.
27.37%到21.70%- >预期更多1.16%到33.75% - >为什么？71.48%到44.55%- >奇怪; 预计会上升Rol*_*DBA 177
每当您增加tmp_table_size和max_heap_table_size时,请记住,设置这些不会使查询表现得更好.它实际上使低效查询的行为比以前更糟糕.在什么情况下？
当查询在ORDER BY没有索引的情况下执行连接或排序(via )时,必须在内存中形成临时表.这会增加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% - >奇怪; 预计会上升
这也就不足为奇了.如果对具有相同值的相同查询有足够的调用,则可以通过执行来自先前缓存的结果的查询来抢占排序和连接.
鉴于这些事情,这里可以调整:
总体目标应该是尽可能地防止临时表的创建.简单地增加tmp_table_size和max_heap_table_size可以让低效的查询和缺乏正确索引的表运行起来.
| 归档时间： |
|
| 查看次数： |
77525 次 |
| 最近记录： |