Em nosso servidor MySQL atual, o cache de consulta está habilitado.
Qchache_hits: 31913
Qchache_inserts: 50959
Qchache_lowmem_prunes: 9320
Qchache_not_chached: 209320
Qchache_queries_in_chace: 986
com_update: 0
com_delete: 0
com_Select: 10
Não entendo completamente o cache de consulta - estou lendo sobre ele atualmente e tentando entendê-lo.
Nosso banco de dados contém dados de estoque, dados de clientes, dados de funcionários, dados de vendas e assim por diante. A consulta raramente é executada mais de uma vez. A possibilidade de uma consulta ser executada duas vezes é visualizar duas vezes uma informação de vendas específica. Mas basicamente tudo no nosso sistema muda constantemente. Ele está sempre sendo atualizado, excluído, inserido e, na minha cabeça, não consigo imaginar os usuários executando a mesma consulta duas vezes em uma semana.
Preciso mesmo ter o cache de consulta ativado? Suponho que as inserções significam que 51 mil entradas foram adicionadas, mas apenas 986 delas estão sendo armazenadas.
Uma ideia seria atualizar o cache, observá-lo por uma semana e verificar quantas consultas em cache são acessadas talvez semanalmente para ver se realmente está retornando algum benefício?
Qualquer ajuda/orientação sobre isso é apreciada, obrigado
Responder1
Sim, 51 mil entradas foram adicionadas, apenas 986 estão lá agora. portanto, havia cerca de 50 mil entradas que foram adicionadas ao cache, mas não estão mais lá, 9 mil delas porque ficaram sem memória no cache e o restante porque inserções/atualizações invalidaram entradas de cache. Com_select é um parâmetro que é útil saber ao tentar decidir se você está obtendo benefícios. Mas, na verdade, depende principalmente de quais consultas estão sendo armazenadas em cache.
Se você estiver executando a instrução select e tiver certeza de que não se beneficiaria com o armazenamento em cache, poderá adicionar SQL_NO_CACHE à instrução select, consultea documentação aqui.
Eu recomendo a leituraEste artigo(e aquele blog em geral).