為什麼 MySQL 在磁碟上創建這麼多臨時表？
任何配置錯誤是否會導致 mysql..mysql 調諧器顯示創建太多臨時表
Current max_heap_table_size = 200 M Current tmp_table_size = 200 M Of 17158 temp tables, 30% were created on disk table_open_cache = 125 tables table_definition_cache = 256 tables You have a total of 97 tables You have 125 open tables. Current table_cache hit rate is 3%早期的臨時表是“在 23725 個臨時表中，有 38% 是在磁碟上創建的”，但我將 max_heap 和 tmp_table 從 16m 更改為 200m，然後降至 30%。
配置：
engine myisam group_concat_max_len = 32768 key_buffer_size = 3.7 GB, thread_stack = 256k, table_cache = 125 query_cache_limit = 1M query_cache_size = 16M join_buffer_size = 2.00 M max_connections = 800另一個具有預設配置的系統顯示“23725 個臨時表，其中 1% 是在磁碟上創建的”具有相同的數據庫。
我嘗試在出現此問題的機器上更改為預設值，但它仍然顯示“在 580 個臨時表中，16% 是在磁碟上創建的”。
我正在使用帶有 48 GB 記憶體的 Ubuntu 11.4 64 位。任何人都可以提出解決方案嗎？
使用“group by”將表上的數據庫引擎從“myisam”更改為“memory”可以解決這個問題嗎？如此處所述：http ://www.mysqlperformanceblog.com/2007/08/16/how-much-overhead-is-caused-by-on-disk-temporary-tables/
mysqltuner 很少提供任何有用的資訊。它使用關於“命中率”的大多數不相關的統計數據，並對可接受的小元件數量進行任意限制。如果您沒有面臨性能問題，那麼您實際上不需要解決它呈現給您的任何問題。話雖如此，這裡有一些關於臨時表的背景資訊……
MySQL 在內部使用 MEMORY 儲存引擎來創建隱式臨時表。在磁碟上的臨時表使用 MyISAM 儲存引擎。
在以下情況下會在磁碟上創建臨時表：
- 存在 TEXT 或 BLOB 欄位（因為 MEMORY 不支持這些類型）
- 生成的隱式臨時表的大小超過
tmp_table_size或max_heap_table_size- 如果將超過 512 字節的列與 GROUP BY 或 UNION 或 ORDER BY 一起使用
閱讀有關內部臨時表的MySQL 文件以獲取更多詳細資訊。
你能做些什麼呢？假設它實際上代表了一個性能問題（而不僅僅是在智力上打擾你）：
- 避免使用 TEXT/BLOB 欄位，而是盡可能使用適當大小的 VARCHAR 或 CHAR 欄位。
- 如果 TEXT/BLOB 是不可避免的，請將它們隔離到具有外鍵關係的單獨表中，並且僅在需要時才加入。
- 像對待上面提到的 TEXT/BLOB 欄位一樣對待超過 512 字節的大列。
- 確保您的查詢只返回您需要的結果集（適當的選擇性 WHERE 子句，避免 SELECT *）
- 避免子查詢並用連接替換它們，尤其是當它們返回一個大的結果集時
- 最後的手段——同時加註
tmp_table_size和max_heap_table_size。除非您發現您的查詢無法優化，否則不要這樣做。如果您擔心自己的 MySQL 配置並且對可用的設置不滿意，您可能需要查看Percona 配置嚮導作為起點。
使用“group by”將表上的數據庫引擎從“myisam”更改為“memory”可以解決這個問題嗎？正如這裡所解釋的
不，它不會，它會讓你的表永遠不會持久化到磁碟上。不要這樣做。