Atualizamos para o MySQL 5.6 e começamos a ver o carregamento do servidor db aumentado significativamente e, finalmente, descobrimos que o query_cache_typepadrão é desativar o start da 5.6.

Nós o ativamos novamente e vemos o carregamento diminuir, por que esse valor está sendo desativado por padrão, a partir do MySQL 5.6? Não consigo ver o problema ativado.

Você precisa do histórico do InnoDB para entender o porquê. Aqui vai:

HISTÓRIA DE GUERRA

O InnoDB e o cache de consultas estão em constante estado de guerra. O InnoDB tende a ser muito pesado ao inspecionar alterações no buffer pool do InnoDB e, em seguida, cruzar o cache de consultas para as mesmas alterações.

TRATADO DE PAZ

Antes do MySQL 5.0, o cache da consulta era desabilitado para o InnoDB. Agora, o InnoDB interage com ele. Para simplificar, basta desabilitar o cache de consultas configurando o query_cache_size como 0.

De acordo com a documentação do MySQL em query_cache_time

Se o servidor for iniciado com o query_cache_type definido como 0, ele não adquirirá o mutex do cache de consulta, o que significa que o cache da consulta não pode ser ativado no tempo de execução e a sobrecarga é reduzida na execução da consulta.

TERMOS DE ENTREGA

Definir query_cache_size como 0 não é uma solução de tamanho único.

A razão da guerra, em primeiro lugar, está no alto. O InnoDB sempre inspecionará as alterações. Um cache de consulta maior tornará o InnoDB muito mais difícil. Desabilitando o cache da consulta, vamos ficar felizes com o InnoDB e o Query Cache. No entanto, você (o desenvolvedor / DBA) pode ser uma vítima dessa guerra por meio de um desempenho ruim de consulta, mesmo com um tratado de paz em vigor.

Dependendo do seguinte

• Carga de trabalho
• Frequência de Mudanças
• Frequência de leitura dos mesmos dados

você deve definir query_cache_size para o número que achar que aumenta o desempenho (isso equivale a iniciar um movimento subterrâneo).

EPÍLOGO

Caso você esteja se perguntando de onde surgiu essa história de guerra, veja meu post antigo

• Sep 05, 2012: A sobrecarga da invalidação frequente do cache de consulta vale a pena?

Leia com atenção, porque eu aprendi isso nas páginas 209-215 do MySQL de alto desempenho (2ª edição)

Eu recomendei desabilitar o cache de consulta para outras pessoas antes

• Sep 25, 2013: invalidando entradas do cache de consulta (chave)
• Sep 26, 2013: valor do acerto do cache de consulta não está mudando no meu banco de dados
• Dec 23, 2013: MySQL com alto uso de CPU e memória

NOTA: Eu sei que a pergunta era sobre o query_cache_type . Isso afeta o cache da consulta. Desativar o cache reduz o domínio do InnoDB sobre ele. Definir manualmente o query_cache_type simplesmente força o Developer / DBA a pensar cuidadosamente sobre o tipo de consultas que o cache de consulta encontrará.

Eu tenho um post no blog explicando por que isso está aqui .

A versão curta: O cache da consulta causa problemas de escalabilidade em máquinas com vários núcleos. Portanto, agora está desativado por padrão.

Para concluir as respostas, a solicitação da Oracle para "substituir" a funcionalidade do cache de consulta é a integração do memcached .