Mysql tmp_table_size max_heap_table_size

Question

在我的服務器上2天前my 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）

如何優化這些結果？

與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% - >奇怪;預期上升

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％，發生了什麼事 - >預期更

這很容易，如果查詢發生在將緩存的結果保留在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加入
  • in indes via inde X掃描爲了

的總體目標應該是防止臨時表創建儘可能。簡單地增加tmp_table_size和max_heap_table_size會導致效率低下的查詢和缺乏適當索引的表運行橫行。