Estou gerenciando um site de comércio eletrônico que usa um popular software de carrinho de compras on-line executado no MySQL 5.6. Ontem notei que SHOW PROCESSLISTrelata que 990 de 1000 consultas estão aguardando um bloqueio de cache de consulta:
mysql> show processlist;
+----------+------------+---------------------+-------------+---------+------+--------------------------------+------------------------------------------------------------------------------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----------+------------+---------------------+-------------+---------+------+--------------------------------+------------------------------------------------------------------------------------------------------+
| 12224065 | sqluser | 10.13.13.13:21716 | mydatabase | Query | 0 | Waiting for query cache lock | SELECT `data` FROM mytable WHERE `foo` = 'bar' |
(...)
No entanto, o tempo é sempre 0 e os IDs do processo mudam o tempo todo. Meu entendimento é que a consulta aguarda um bloqueio de tabela, mas o bloqueio é liberado em menos de um segundo.
Este é um comportamento normal/aceitável ou vale a pena fazer alguns ajustes no cache de consulta, talvez removê-lo completamente?
Este é um sinal muito claro de que seu cache de consulta MySQL está fazendo mais mal do que bem em sua carga de trabalho. Há um gargalo de serialização onde sempre que qualquer tabela é gravada, se houver uma consulta que tocou nessa tabela armazenada em cache no cache de consulta, o cache de consulta deve ser bloqueado e limpo de quaisquer consultas em cache que se refiram a essas tabelas. Em muitos casos, isso faz mais mal do que bem.
O cache de consulta fornece benefícios tangíveis apenas em bancos de dados em que as gravações são poucas e pouco frequentes.