Este artigo foi reproduzido do número público "engenheiro de soluções MySQL", autor: Xuyi Tao
O MySQL tinha um cache de consulta antes, o Query Cache. A partir de 8.0, esse cache de consulta não é mais usado, então qual é o motivo para desistir dele? Neste artigo, apresentarei a você.
O cache de consulta MySQL é um cache de resultado de consulta. Ele compara a consulta que começa com SEL com a tabela de hash e, se houver correspondência, retorna o resultado da consulta anterior. Ao corresponder, a consulta deve ser combinada byte a byte, por exemplo, SELECT * FROM t1; não é igual a select * from t1 ;. Além disso, alguns resultados de consulta incertos não podem ser armazenados em cache e qualquer modificação na tabela invalidará todos os caches dessas tabelas . Portanto, a solução mais ideal para o cache de consulta é somente leitura, especialmente para consultas complexas que retornam apenas algumas linhas após verificar milhões de linhas. Se sua consulta atender a essa característica, ativar o cache de consulta melhorará o desempenho da consulta.
Com o avanço da tecnologia e o teste do tempo, a equipe de engenharia do MySQL descobriu que não há muitos benefícios em habilitar o cache.
Em primeiro lugar, o efeito do cache de consulta depende da taxa de acertos do cache. Apenas o efeito da consulta que atinge o cache pode ser melhorado, portanto, seu desempenho não pode ser previsto.
Em segundo lugar, outro grande problema com o cache de consulta é que ele é protegido por um único mutex. Em servidores com vários núcleos, um grande número de consultas pode levar a um grande número de contenção mutex.
Por meio de testes de benchmark, descobriu-se que a maioria das cargas de trabalho são melhores para desabilitar o cache de consulta (configuração padrão de 5,6): query_cache_type = 0
Se você acha que se beneficiará com o cache de consulta, teste de acordo com as condições reais.
Quanto mais dados são gravados, menos benefícios
Quanto mais dados estiverem contidos no buffer pool, menor será o benefício
Quanto mais complexa a consulta e maior o intervalo de varredura, mais beneficiado
Outra razão para o MySQL8.0 cancelar o cache de consulta é que a pesquisa mostra que quanto mais próximo o cache está do cliente, maiores são os benefícios. Para esta pesquisa, consulte https://proxysql.com/blog/scaling-with-proxysql-query-cache/
A imagem abaixo é do URL acima:
Além disso, o MySQL 8.0 adicionou novas ferramentas para intervenção de desempenho.Por exemplo, plug-ins de reescrita de consulta agora podem ser usados para inserir instruções de prompt do otimizador sem alterar o aplicativo. Além disso, existem ferramentas de terceiros, como ProxySQL, que podem atuar como caches intermediários.
Com base nos motivos acima, o MySQL 8.0 não oferece mais suporte para cache de consulta. Se os usuários atualizarem da versão 5.7 para 8.0, considere o uso de reescrita de consulta ou outro cache.
O texto completo acabou.
Aproveite o MySQL 8.0 :)
A aula "MySQL Core Optimization" do professor Ye foi atualizada para o MySQL 8.0, leia o código para iniciar a jornada de prática do MySQL 8.0