Configuración óptima de tablas temporales de MySQL (tablas de memoria)?

Question

Antes que nada, soy nuevo en la optimización de mysql. El hecho es que tengo en mi aplicación web (alrededor de 400 consultas por segundo), una consulta que usa un GROUP BY que no puedo evitar y que es la causa de la creación de tablas temporales. Mi configuración es:

max_heap_table_size = 16M 
tmp_table_size = 32M 

El resultado: tabla temporal a ciento disco + - 12,5%

Luego cambié mi configuración, según this post

max_heap_table_size = 128M 
tmp_table_size = 128M 

El resultado: tabla temporal en el disco por ciento + - 18%

No se esperaban los resultados, no entiendo por qué.

Es incorrecto tmp_table_size = max_heap_table_size? ¿No debería aumentar el tamaño?

consulta

SELECT images, id 
FROM classifieds_ads 
WHERE parent_category = '1' AND published='1' AND outdated='0' 
GROUP BY aux_order 
ORDER BY date_lastmodified DESC 
LIMIT 0, 100; 

EXPLIQUE

| 1 |SIMPLE|classifieds_ads | ref |parent_category, published, combined_parent_oudated_published, oudated | combined_parent_oudated_published | 7 | const,const,const | 67552 | Using where; Using temporary; Using filesort | 

Answer 1

"Uso temporal" en el informe de explicar no nos dice que la tabla temporal fue en el disco. Solo nos dice que la consulta espera crear una tabla temporal.

La tabla temporal se quedará en la memoria si su tamaño es menor que tmp_table_size y menos de max_heap_table_size.

Max_heap_table_size es la tabla más grande que puede encontrarse en el motor de almacenamiento MEMORY, ya sea que se trate de una tabla temporal o no temporal.

Tmp_table_size es la tabla más grande que puede haber en la memoria cuando se crea automáticamente mediante una consulta. Pero esto no puede ser mayor que max_heap_table_size de todos modos. Por lo tanto, no es beneficioso establecer tmp_table_size mayor que max_heap_table_size. Es común establecer estas dos variables de configuración en el mismo valor.

Puede supervisar cómo se crearon muchas tablas temporales, y cuántos en el disco como esto:

mysql> show global status like 'Created%'; 
+-------------------------+-------+ 
| Variable_name   | Value | 
+-------------------------+-------+ 
| Created_tmp_disk_tables | 20 | 
| Created_tmp_files  | 6  | 
| Created_tmp_tables  | 43 | 
+-------------------------+-------+ 

Nota en este ejemplo, se crearon 43 tablas temporales, pero sólo 20 de ellos estaban en el disco.

Cuando aumenta los límites de tmp_table_size y max_heap_table_size, permite que existan tablas temporales más grandes en la memoria.

Puede preguntar, ¿qué tan grande necesita hacerlo? No necesariamente es necesario que sea lo suficientemente grande para que cada tabla temporal encaje en la memoria. Es posible que desee que el 95% de las tablas temporales quepan en la memoria y que solo las tablas extrañas restantes entren en el disco. Es posible que el último 5% sea muy grande, mucho más grande que la cantidad de memoria que desea usar para eso.

Mi práctica es aumentar tmp_table_size y max_heap_table_size de forma conservadora. Luego mire la proporción de Created_tmp_disk_tables a Created_tmp_tables para ver si he cumplido con mi objetivo de hacer que el 95% permanezca en la memoria (o la proporción que deseo ver).

Desafortunadamente, MySQL no tiene una buena manera de decir exactamente lo grande que eran las tablas temporales. Eso variará por consulta, por lo que las variables de estado no pueden mostrar eso, solo pueden mostrarle un recuento de cuántas veces ha ocurrido. Y EXPLAIN en realidad no ejecuta la consulta, por lo que no puede predecir con exactitud cuántos datos coincidirá.

Una alternativa es Percona Server, que es una distribución de MySQL con mejoras. Uno de estos es a log extra information in the slow-query log. Se incluye en los campos adicionales el tamaño de las tablas temporales creadas por una consulta determinada.