cómo borrar/eliminar mysql innodb buffer pool?

Question

Estoy afinando una consulta grande, y quiero ejecutarla desde la misma línea de base antes y después, para comparar.

Sé acerca de la caché de consultas de mysql, pero no es relevante para mí, ya que las 2 consultas no se almacenarían en caché de todos modos.

Lo que se está almacenando en caché, son las páginas innodb, en el grupo de búferes. ¿Hay alguna manera de borrar todo el grupo de búferes para que pueda comparar las dos consultas desde el mismo punto de partida?

Mientras que reiniciar el servidor MySQL después de ejecutar cada consulta habría ningún trabajo dudas, Id gustaría evitar esto si es posible

Answer 1

ADVERTENCIA: El siguiente sólo funciona para MySQL 5.5 y MySQL 5.1.41+ (InnoDB Plugin)

Tweek la duración de las entradas de la agrupación de almacenamiento intermedio InnoDB con estos valores:

SET GLOBAL innodb_old_blocks_time=250; // This is 0.25 seconds 
SET GLOBAL innodb_old_blocks_pct=5; 
SET GLOBAL innodb_max_dirty_pages_pct=0; 

Cuando haya terminado la prueba, el establecimiento de vuelta a los valores por defecto:

SET GLOBAL innodb_old_blocks_time=0; 
SET GLOBAL innodb_old_blocks_pct=37; 
SET GLOBAL innodb_max_dirty_pages_pct=90; // 75 for MySQL 5.5/MySQL 5.1 InnoDB Plugin 

Mira la definición de estos ajustes

• MySQL 5,5
  • innodb_old_blocks_time
  • innodb_old_blocks_pct
  • innodb_max_dirty_pages_pct
• MySQL 5.1.41+
  • innodb_old_blocks_time
  • innodb_old_blocks_pct
  • innodb_max_dirty_pages_pct

Answer 2

Mucho más simple ... Ejecutar este doble

SELECT SQL_NO_CACHE ...; 

y mirar el segundo tiempo.

El primero calienta el buffer_pool; el segundo evita el control de calidad teniendo SQL_NO_CACHE.

Por lo tanto, la segunda temporización es una buena indicación de cuánto tiempo lleva en un sistema de producción con una memoria caché caliente.

Además, Mira Handler cuenta

FLUSH STATUS; 
SELECT ...; 
SHOW SESSION STATUS LIKE 'Handlers%'; 

da una idea bastante clara de cuántas filas se toquen. Eso, a su vez, le da una buena idea de cuánto esfuerzo requiere la consulta. Tenga en cuenta que esto se puede ejecutar con bastante éxito (y rápidamente) en pequeños conjuntos de datos. Luego puede (a menudo) extrapolar a conjuntos de datos más grandes.

Un "Handler_read" podría estar leyendo una fila de índice o una fila de datos. Puede ser la fila 'siguiente' (de ahí probablemente almacenada en caché en el bloque que se leyó para la fila anterior), o podría ser aleatoria (por lo tanto, posiblemente esté sujeta a otro golpe de disco). Es decir, la técnica no ayuda mucho con "cuántos bloques se necesitan".

Esta técnica de manejo es impermeable a lo que está sucediendo; da resultados consistentes

"Handler_write" indica que se necesitaba una tabla tmp.

Los números que se aproximan al número de filas en la tabla (o un múltiplo de tales), probablemente indican un escaneo de tabla (s). Un número que es el mismo que LIMITpodría significa que usted genera un índice tan bueno que consumió el LIMIT en sí mismo.

Si lo hace tirar de la agrupación de almacenamiento, se podía observar los cambios en Innodb_buffer_pool_reads para dar una precisa (?) La cuenta del número de páginas leídas en un sistema de frío. Esto incluiría páginas de índice no hojas, que casi siempre están en caché. Si algo más está sucediendo en el sistema, este valor STATUS no debería ser confiable porque es 'global', no 'sesión'.