Nos hemos actualizado a MySQL 5.6 y comenzamos a ver que la carga del servidor db aumentó significativamente, y finalmente descubrimos que el valor query_cache_typepredeterminado es 5.6.

Lo habilitamos nuevamente y vemos que la carga disminuye, ¿por qué este valor se deshabilita de manera predeterminada desde MySQL 5.6? No puedo ver el problema en habilitado.

Necesita la historia de InnoDB para comprender por qué. Aquí va:

HISTORIA DE GUERRA

InnoDB y la caché de consultas están en un estado de guerra constante. InnoDB tiende a ser muy duro cuando inspecciona los cambios en el InnoDB Buffer Pool y luego realiza una verificación cruzada de Query Cache para los mismos cambios.

TRATADO DE PAZ

Antes de MySQL 5.0, el caché de consultas estaba deshabilitado para InnoDB. Ahora, InnoDB interactúa con él. Para simplificar las cosas, puede deshabilitar Query Cache estableciendo query_cache_size en 0.

De acuerdo con la documentación de MySQL en query_cache_time

Si el servidor se inicia con query_cache_type establecido en 0, no adquiere el mutex de la caché de consulta, lo que significa que la caché de consulta no se puede habilitar en tiempo de ejecución y hay una sobrecarga reducida en la ejecución de la consulta.

TÉRMINOS DE ENTREGA

Establecer query_cache_size en 0 no es una solución única para todos.

La razón de la guerra, en primer lugar, es general. InnoDB siempre inspeccionará los cambios. Un caché de consultas más grande hará que InnoDB trabaje mucho más duro. Al deshabilitar la caché de consultas, InnoDB y Query Cache estarán felices. Sin embargo, usted (el Desarrollador / DBA) podría ser una víctima de esa guerra por el mal desempeño de las consultas, incluso con un tratado de paz.

Dependiendo de lo siguiente

• Carga de trabajo
• Frecuencia de cambios
• Frecuencia de lectura de los mismos datos.

debes establecer query_cache_size en cualquier número que creas que aumenta el rendimiento (esto equivale a comenzar un movimiento subterráneo).

EPÍLOGO

En caso de que se pregunte dónde se me ocurrió esta historia de guerra, consulte mi publicación anterior

• Sep 05, 2012: ¿Vale la pena la sobrecarga de la invalidación frecuente de la caché de consultas?

Léalo detenidamente porque aprendí esto de las páginas 209-215 de MySQL de alto rendimiento (2a edición)

He recomendado deshabilitar el caché de consultas a otros antes

• Sep 25, 2013: invalidación de entradas de caché de consultas (clave)
• Sep 26, 2013: el valor de hit de la caché de consulta no está cambiando en mi base de datos
• Dec 23, 2013: MySQL con alto uso de CPU y memoria

NOTA: Me doy cuenta de que la pregunta era sobre query_cache_type . Tiene un efecto en la caché de consultas. Deshabilitar el caché aplasta el dominio de InnoDB sobre él. Establecer el query_cache_type manualmente simplemente obliga al Desarrollador / DBA a pensar cuidadosamente sobre el tipo de consultas que encontrará el caché de consultas.

Tengo una publicación de blog que explica por qué esto está aquí .

La versión corta: el caché de consultas causa problemas de escalabilidad en máquinas de múltiples núcleos. Por lo tanto, ahora está deshabilitado de forma predeterminada.

Para completar las respuestas, el impulso de Oracle para "reemplazar" la funcionalidad de caché de consultas es la integración memcached .