¿Por qué MySQL está creando tantas tablas temporales en el disco?

¿Cualquier error de configuración puede llevar a crear demasiadas tablas temporales por mysql..mysql tuner shows

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%

La tabla temporal anterior era "de las 23725 tablas temporales que el 38% se crearon en el disco", pero cambié max_heap y tmp_table a 200m desde 16m y bajó al 30%.

Configuración:

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

Otro sistema con configuración predeterminada muestra "de 23725 tablas temporales, 1% fueron creadas en disco" con la misma base de datos.

Intenté cambiar el valor predeterminado en la máquina con este problema y todavía muestra "De las 580 tablas temporales, el 16% se crearon en el disco".

Estoy usando Ubuntu 11.4 de 64 bits con 48 gb de ram. ¿Puede alguien sugerir una solución?

¿Cambiar el motor de db de "myisam" a "memoria" en las tablas usando "group by" arreglará esto? Como se explica aquí: http://www.mysqlperformanceblog.com/2007/08/16/how-much-overhead-is-caused-by-on-disk-temporary-tables/

mysqltuner rara vez proporciona información útil. Utiliza en su mayoría estadísticas irrelevantes sobre las "tasas de éxito" y pone límites arbitrarios a lo que es aceptable un número aceptable de widgets. Si no se enfrenta a un problema de rendimiento, no necesita resolver ninguno de los problemas que le presenta. Dicho esto, aquí hay una pequeña información de fondo sobre tablas temporales ...

MySQL usa internamente el motor de almacenamiento MEMORY para crear tablas temporales implícitas. En las tablas temporales del disco, use el motor de almacenamiento MyISAM.

Las tablas temporales se crean en el disco cuando:

• Los campos TEXTO o BLOB están presentes (porque MEMORIA no admite estos tipos)
• el tamaño de la tabla temporal implícita resultante excede el menor de tmp_table_sizeomax_heap_table_size
• Si se usa una columna con más de 512 bytes con GROUP BY o UNION u ORDER BY

Lea la documentación de MySQL sobre tablas temporales internas para obtener más detalles.

¿Qué puedes hacer al respecto? Presumiendo que en realidad representa un problema de rendimiento (en lugar de solo molestarte intelectualmente):

• Evite los campos TEXTO / BLOB y, en su lugar, use los campos VARCHAR o CHAR del tamaño apropiado cuando sea posible.
• Si TEXT / BLOB son inevitables, sujételos para separar tablas con una relación de clave externa y ÚNASE solo cuando los necesite.
• Trate las columnas grandes, más de 512 bytes como lo haría con los campos TEXT / BLOB mencionados anteriormente.
• Asegúrese de que sus consultas solo devuelvan el conjunto de resultados que necesita (cláusulas WHERE apropiadamente selectivas, evite SELECT *)
• Evite las subconsultas y reemplácelas con combinaciones, especialmente si devuelven un conjunto de resultados grande
• Último recurso: elevar ambos tmp_table_sizey max_heap_table_size. No haga esto a menos que encuentre que sus consultas no se pueden optimizar.

Si le preocupa su configuración de MySQL y no se siente cómodo con la configuración disponible, puede consultar el Asistente de configuración de Percona como punto de partida.

¿Cambiar el motor de db de "myisam" a "memoria" en las tablas usando "group by" arreglará esto? como se explica aquí

No, no lo hará y lo hará de tal manera que sus tablas nunca sean persistentes en el disco. No hagas esto.

¡"usar temporal" y "usar ordenar archivos" no son el fin del mundo!

SELECCIONE ... GRUPO POR a, b ORDEN POR c, d - Requiere 1 o 2 "tablas temporales".

Simplemente hay momentos en que sus consultas usarán tablas temporales. Las tablas temporales pueden ralentizar una consulta por un pequeño factor. Pero si la consulta sigue siendo "lo suficientemente rápida", no se preocupe.

Si la consulta es demasiado lenta (con o sin tablas tmp), hablemos de ello. Proporcione SHOW CREATE TABLE, SHOW TABLE STATUS y EXPLAIN.