Início / dba / Perguntas / 217577
Accepted
shaoyihe
Asked: 2018-09-14 17:38:16 +0800 CST

Por que o MySQL removeu o recurso de cache de consulta após a versão 8.0?

  • 772

Por que o MySQL removeu o recurso de cache de consulta após a versão 8.0?

mysql query-cache

3 respostas

  1. Best Answer

    Há um blog detalhado da equipe do servidor MySQL sobre isso, onde Matt Lord diz:

    O cache de consulta foi desabilitado por padrão desde o MySQL 5.6 (2013), pois é conhecido por não ser dimensionado com cargas de trabalho de alto rendimento em máquinas com vários núcleos.

    Consideramos quais melhorias poderíamos fazer no cache de consulta versus otimizações que poderíamos fazer que fornecem melhorias para todas as cargas de trabalho.

    Embora essas escolhas sejam ortogonais, os recursos de engenharia são finitos. Isso quer dizer que estamos mudando a estratégia para investir em melhorias que são mais aplicáveis ​​a todas as cargas de trabalho.

    • 18

  2. Boa despedida!!!

    É um desafio para a maioria dos desenvolvedores de banco de dados estimar corretamente o tamanho dos conjuntos de resultados mais comuns em seus aplicativos. Ter um cache de consulta grande era apenas um grande curativo para isso.

    Há uma razão maior que prenunciou o fim do cache de consulta: Quatro anos atrás ( June 07, 2014), respondi ao post Por que query_cache_type está desabilitado por padrão a partir do MySQL 5.6? . Resumindo, o cache de consulta estava sempre inspecionando o InnoDB Buffer Pool em busca de alterações. Você pode encontrar isso nas páginas 209-215 do MySQL de alto desempenho (2ª edição) .

    Eu mencionei isso ao longo dos anos:

    Cache de consulta RIP !!!

    • 11

  3. (Concordo com a outra resposta, mas aqui está o meu valor de 2 centavos.)

    Conforme implementado, ...

    • O QC não pode funcionar com Galera ou Group Replication, os quais estão ganhando mais força na arena de HA.

    • Quando query_cache_sizeficou grande, ficou menos eficiente. Isso se deve a ineficiências na "poda". (Observação: o Aurora o reimplementou e parece ter corrigido esse problema.)

    • Há uma sobrecarga em cada SELECT porque não sabe se o QC entrará em jogo. Décadas atrás, isso era estimado em 11%. Até se livrar do QC, a única solução era fazer as duas coisas query_cache_size = 0 e query_cache_type = 0 no arquivo de configuração. (Poucas pessoas perceberam que ambos eram necessários.)

    • No servidor de produção típico, as inserções acontecem com frequência. Como cada inserção causava uma poda de todas as entradas para essa(s) tabela(s), o QC era praticamente inútil para essas tabelas.

    • Talvez 95% das centenas de sistemas que revisei quanto a problemas de desempenho estejam melhores sem o CQ.

    • 6

relate perguntas