MyISAM: vantagens e desvantagens.

O mecanismo de armazenamento MyISAM, padrão no MySQL até a versão 5.5, é o mais usado na WEB, em armazéns ou depósitos de dados e vários outros tipos de aplicações.
Neste texto, vou mostrar algumas de suas características e as situações onde o seu uso é indicado e quando não é.
Escolher o mecanismo de armazenamento (ou storage engine) mais adequado pras suas aplicações é crucial e uma decisão errada tomada nesta escolha pode ser de difícil reversão.
Antes do MySQL 5.5.5, ao criar uma nova tabela, o padrão escolhido pelo sistema será o MyISAM, a menos que você especifique outro. A partir desta versão, o padrão será o InnoDB.

SAIBA MAIS:
O mecanismo de armazenamento MyISAM é derivado de um outro, mais antigo, chamado ISAM — Indexed Sequential Access Method, originalmente desenvolvido pela IBM, para ser usado em mainframes. Ainda dentro da IBM, o ISAM evoluiu pro VSAM — Virtual Storage Access Method.
Atualmente, a IBM promove o uso do DB2.
Era possível usar o mecanismo de armazenamento ISAM até o MySQL 3.23. A partir de então, ele se tornou indisponível, embora seu código ainda estivesse incluído até a versão 4.1.
Conheça outros mecanismos de armazenamento para MySQL.

As vantagens de usar o MyISAM

Atualmente, muitas distros Linux oferecem o MySQL em seus repositórios e, no Ubuntu 14.04 é a versão 5.5 que ainda estará lá, para ser baixada — onde o mecanismo de armazenamento padrão é o MyISAM. A Canonical tem planos de mudar do MySQL para MariaDB em um futuro próximo.
Eu posso citar, pelo menos, 4 boas razões para usar o MyISAM storage engine.

1 – a simplicidade

As tabelas MyISAM são simples. Se você é novato no assunto “bancos de dados” ou no que concerne ao MySQL, é recomendado começar a usar o MyISAM, antes de sair experimentando os outros.
Segue um exemplo de como criar um novo banco de dados e uma tabela no MySQL.
(Se você ainda não tem o MySQL instalado, dê uma olhada no artigo Como instalar o MySQL).
Para criar um banco de dados, usamos a declaração CREATE DATABASE. Em seguida, o selecionamos para uso, com USE. Veja como:

CREATE DATABASE teste;
USE teste;

Uma vez criado o banco e selecionado para uso, vamos criar uma nova tabela dentro dele:

CREATE TABLE teste.meuslivros (
id int UNSIGNED NOT NULL AUTO_INCREMENT,
titulo TEXT NOT NULL;
autor VARCHAR(30)
genero VARCHAR(20),
PRIMARY KEY(id))
ENGINE = MyISAM;

O exemplo, acima, mostra como é simples e rápida a criação de uma nova tabela no MySQL. Se você tiver interesse, o artigo – como criar tabelas no MySQL –, mostra o processo com mais exemplos e detalhes.

2 – otimização e base de conhecimento

Eu poderia dizer que o MyISAM é muito rápido – mais rápido que muitos outros storage engines, mas os benchmarks feitos por várias empresas mostram resultados muito diferentes entre si. Esta variação se deve às tarefas executadas, às configurações dos servidores e do mysqld, entre outros fatores. A melhor medição, quem faz, é você, dentro do seu ambiente de trabalho. Ainda assim, é notória a performance do mecanismo de armazenamento MyISAM, nos testes.
Em função do tempo em que o MyISAM tem estado “na estrada”, há muitos sistemas plenamente otimizados para usa-lo.
Se você sente que o seu sistema não está perfeitamente otimizado para uso do MyISAM, há uma extensa base de conhecimento disponível na Internet para ajudá-la(o) a resolver isto.

3 – indexação FULLTEXT e busca dentro do banco de dados

Considerando a tabela que criamos, imagine que precisamos realizar uma pesquisa, percorrendo títulos e gêneros dos livros.
Uma solução simples, possibilitada pelo MyISAM é adicionar um índice FULLTEXT. Veja o exemplo:

ALTER TABLE teste.livros ADD FULLTEXT alltext (autor, genero);

Agora, fica fácil encontrar todos os livros que contenham as palavras “mauro vasconcelos” e “infanto-juvenil”, dentro da tabela:

SELECT * FROM teste.livros WHERE MATCH(autor, genero) AGAINST ('mauro vasconcelos infanto-juvenil');

Com uma alteração na declaração acima, é possível obter o mesmo resultado, só que ordenado por relevância. Veja:

SELECT *, MATCH(autor, genero) AGAINST ('mauro vasconcelos infanto-juvenil') FROM teste.livros ORDER BY rel DESC;

4 – uso de recursos em ambientes limitados

Uma das vantagens de qualquer sistema que tem longa estrada percorrida é a estabilidade conquistada pelos anos de uso, pessoas envolvidas no projeto e seu contínuo desenvolvimento.
O MyISAM é o mais indicado em sistemas de poucos recursos, em servidores de menor capacidade de processamento e/ou com pouco espaço de armazenamento em disco ou memória RAM.
Nesta arena, ele se mostra imbatível nos benchmarks de que falamos no item anterior, mesmo que você não dedique algum tempo a otimizar o hardware e o mysqld.

As desvantagens do mecanismo de armazenamento de tabelas MyISAM

Se há situações em que o MyISAM é o mais indicado para uso, há várias outras em que ele é superado por outros mecanismos.
Aqui, vou mostrar alguns dos problemas que administradores e programadores enfrentam ao usar o MyISAM, no MySQL.

1 – integridade de dados

O MyISAM não tem suporte a transações ou a restrições de chaves estrangeiras.
Leve em conta uma aplicação bancária, onde ocorre uma transferência monetária – o que envolveria duas declarações SQL UPDATE: uma para debitar o valor de uma conta; outra para creditar o mesmo valor à outra conta.
Se houvesse uma falha no servidor, exatamente neste momento, você poderia acabar com o valor nas duas contas ou em nenhuma delas. O recurso de “transações”, presente no InnoDB, é o que evita este tipo de situação.

2 – recuperação de acidentes

O MySQL é estável e confiável. Contudo, as tabelas MyISAM podem voltar corrompidas, após uma falha.
O problema pode ser resolvido com o uso de um REPAIR TABLE – o que é um trabalho administrativo a mais, na verdade.

3 – travamento de tabelas

Ao adicionar ou atualizar um registro em uma tabela MyISAM, todas as outras mudanças são impedidas pelo travamento, até que aquela operação seja completada.
É difícil demonstrar ou provar que este comportamento diminui a performance ou causa problemas à sua aplicação web, mas há um consenso entre especialistas de que o mecanismo mais adequado para você não é o MyISAM, se a sua aplicação realiza grandes quantidades de inserções e atualizações à tabela.

LEIA MAIS:
  • Busca FULLTEXT — leia mais sobre pesquisas via FULLTEXT Index no MySQL.
  • Storage engines — conheça os mecanismos de armazenamento suportados pelo MySQL.
  • Tipos de dados — conheça os tipos de dados suportados dentro das tabelas MySQL
  • mysqlcheck — veja como restaurar uma tabela corrompida.
  • Bancos de dados — veja como criar novos bancos de dados no MySQL.
  • Tabelas — aprenda, através de exemplos, como criar tabelas no MySQL.

Conclusão: devo usar o MyISAM?

Há uma série de situações em que o MyISAM tende a ser a opção mais indicada, de acordo com a relação de vantagens e desvantagens apresentada, até agora. Nas situações, abaixo, a resposta é sim:

  • Você é iniciante no MySQL;
  • Sua aplicação web é simples e não precisa de transações;
  • Você precisa de velocidade;
  • Deseja usar buscas FULLTEXT;
  • Tem recursos de hardware limitados.

Já, se precisa fazer uso de “transactions” e a integridade dos dados é prioritária e crítica, outras opções devem ser consideradas.
Note que é comum se usar mais de um tipo de mecanismo de armazenamento dentro de um mesmo banco de dados. Algumas tabelas precisam usar o InnoDB, outras o MyISAM e outras podem usar o CSV – e todo mundo convive bem, sem problema algum.
Os tipos de aplicações mais indicados para usar o MyISAM são:

  • CMS – Content Management Systems, ou sistemas de gestão de contúdo;
  • Ferramentas de marcação de páginas favoritas online;
  • Leitores RSS;
  • Mecanismos de busca na web etc.

Espero que este texto tenha lhe sido útil e, se este for o caso, compartilhe com os seus amigos, nas redes sociais. Esta é sempre a melhor forma de agradecer e incentivar.

MySQL: use o mysqlcheck para fazer manutenção das suas tabelas

O programa cliente mysqlcheck oferece uma maneira eficiente para executar a manutenção das tabelas em seu banco de dados — ele verifica, conserta, otimiza ou apenas analisa as tabelas dentro do banco de dados.
O mysqlcheck deve ser usado quando o servidor mysqld está rodando — uma de suas primeiras vantagens é essa: a de não precisar indisponibilizar o servidor para fazer uma manutenção no seu sistema de banco de dados.
O mysqlcheck é um “frontend”. Ele se autentica no MySQL e execute as declarações CHECK TABLE, REPAIR TABLE, ANALYZE TABLE e OPTIMIZE TABLE do modo mais conveniente pro usuário. Ele determina a forma mais adequada para cada declaração de acordo com a operação pedida, na linha de comando, e a envia ao servidor para ser executada.
É o indicado para realizar as tarefas de manutenção em tabelas MyISAM. Outros mecanismos de armazenamento (storage engines) podem não suportar todas as operações, nestes casos, mensagens de erro irão surgir para te informar do fato:

note    : The storage engine for the table doesn't support check
PRECAUÇÕES

Você deve fazer backup dos dados nas tabelas antes de inciar uma operação de restauração (repair) nestas tabelas. Sob certas circunstâncias, a operação pode causar perda de dados.
Algumas causas de perda de dados podem estar ligadas a sistemas de arquivos com erros.

De acordo com o manual oficial do MySQL, há 3 sintaxes possíveis pro comando mysqlcheck:

mysqlcheck [opcoes] nome_do_banco [nome_da_tabela1 nome_da_tabela2 ...]
mysqlcheck [opcoes] --databases nome_do_banco1 nome_do_banco2 ...
mysqlcheck [opcoes] --all-databases

Daqui pra frente, vamos desenvolver melhor o assunto e algumas das opções mais comuns de uso do comando.

Como verificar uma tabela dentro do banco de dados

Se seu aplicativo retornou uma mensagem de erro, informando que uma determinada tabela está corrupta, execute o mysqlcheck assim:

mysqlcheck -c nome_do_banco nome_da_tabela -u root -p

forneça a senha, assim que lhe for pedido e aguarde o resultado:

nome_do_banco.nome_da_tabela      OK

Se a senha e/ou nome de usuário estiver errada, o sistema emitirá uma mensagem de erro semelhante a esta:

mysqlcheck: Got error: 1045: Access denied for user 'root'@'localhost' (using password: NO) when trying to connect

A opção -c é a que indica que a operação a ser realizada é de checagem (verificatória).

Como verificar todas as tabelas em um banco de dados

Se quiser verificar todas as tabelas dentro de um banco de dados, com o mysqlcheck, omita seus nomes. Forneça apenas o nome do banco de dados que as contém (no meu caso, é clientes):

mysqlcheck -c clientes -u root -p

O meu resultado foi este:
clientes.CLPJ OK
clientes.CLCD OK
clientes.CLPD OK
clientes.CLCT OK[/plain]

Como checar todas as tabelas e bancos de dados

Para realizar uma checagem desta amplitude, o comando executado é bem curto:

mysqlcheck c -u root -p --all-databases

Você pode executar o mysqlcheck em mais de um banco de dados (sem ser todos), assim, com a opção --databases. No exemplo, que segue, o comando será executado em todas as tabelas dentro dos bancos de dados fornecedores e clientes:

mysqlcheck -c -u root -p --databases fornecedores clientes

Como analisar tabelas usando o mysqlcheck

O exemplo que segue, usa o comando mysqlcheck, com a opção -a para analisar a tabela cadastros, dentro do banco de dados clientes:

mysqlcheck -a clientes cadastros -u root -p

Internamente, o mysqlcheck roda a declaração ANALYZE TABLE em relação à clientes. Enquanto trabalha, trava a tabela, permitindo apenas a sua leitura – motivo, pelo qual, você não deve fazer estas tarefas em horários de pico.

Use o mysqlcheck para otimizar tabelas

No exemplo que segue, o mysqlcheck é usado para otimizar a tabela projetos, dentro do banco de dados clientes.

mysqlcheck -o clientes projetos -u root -p
Enter password: 
clientes.projetos                                  Table is already up to date

Como já disse, o comando mysqlcheck executa um comando MySQL internamente. Neste caso, o OPTIMIZE TABLE.
À medida em que você vai removendo registros das suas tabelas, espaços sem uso vão ficando no meio. Este comando funciona semelhante ao desfragmentador de alguns sistemas operacionais, reorganizando os espaços, o que melhora a performance em tabelas que já tenham passado por grandes quantidades de alterações.

Restaure, conserte tabelas com o comando mysqlcheck

Aqui, o mysqlcheck vai usar internamente o comando REPAIR TABLE, que repara (conserta) uma tabela MyISAM corrompida.
Veja como:

mysqlcheck -r clientes projetos -u root -p

Combine diversas tarefas em uma só declaração mysqlcheck

É claro que, para a sua comodidade, é possível combinar diversas tarefas para serem executadas pelo mysqlcheck, em apenas uma linha de comando. veja como combinar CHECK, OPTIMIZE e REPAIR e mais a opção --auto-repair, dentro do banco de dados clientes (adeque o comando à sua realidade):

mysqlcheck -u root -p --auto-repair -o clientes

Ou em todas as tabelas, em todos os bancos de dados:

mysqlcheck -u root -p --auto-repair -o --all-databases
LEIA MAIS:
  • Comandos (internos) de manutenção — rápida noção dos comandos REPAIR, ANALYZE, CHECK e OPTIMIZE.
  • Otimize suas consultas — use o QUERY CACHE!
  • Outras opções úteis pro mysqlcheck

    Para ter um feedback maior do que está sendo feito pelo programa, use a opção –debug-info. Ela é mais voltada para encontrar erros dentro do próprio programa, para desenvolvedores – mas é uma mão na roda para administradores de MySQL que desejam ter um maior controle do que o comando está executando. Veja, no exemplo, como a saída oferece mais informações.

    mysqlcheck -u root -p --debug-info --auto-repair clientes projetos
    Enter password: 
    clientes.projetos                                  OK
    User time 0.01, System time 0.00
    Maximum resident set size 1584, Integral resident set size 0
    Non-physical pagefaults 538, Physical pagefaults 0, Swaps 0
    Blocks in 0 out 0, Messages in 0 out 0, Signals 0
    Voluntary context switches 3, Involuntary context switches 17

    MySQL: comandos para manutenção do banco de dados

    De maneira bem breve, vou listar 4 comandos MySQL relacionados à manutenção dos seus bancos de dados. Neste texto, serão descritos de forma bem sucinta e rápida. É mais ou menos um lembrete para quem é administrador iniciante e ainda não criou os bons hábitos de verificação dos seus bancos de dados.

    Check table

    Com suporte ao MyISAM e ao InnoDB, o comando CHECK TABLE pode ser usado para verificar erros e inconsistências nas tabelas.
    Sua sintaxe é simples mas você precisa ter privilégios adequados para poder rodar este comando:

    
    CHECK TABLE projetos QUICK;
    
    +-------------------+-------+----------+----------+
    | Table             | Op    | Msg_type | Msg_text |
    +-------------------+-------+----------+----------+
    | clientes.projetos | check | status   | OK       |
    +-------------------+-------+----------+----------+
    1 row in set (0.09 sec)
    

    Repair table

    Se houver erros detectados por CHECK TABLE, será necessário usar o REPAIR na sua tabela.

    
    REPAIR TABLE projetos;
    
    +-------------------+--------+----------+----------+
    | Table             | Op     | Msg_type | Msg_text |
    +-------------------+--------+----------+----------+
    | clientes.projetos | repair | status   | OK       |
    +-------------------+--------+----------+----------+
    1 row in set (0.00 sec)
    

    Analyze table

    Este comando (exemplo abaixo) analisa e armazena a distribution key da tabela. Enquanto isto, ele a trava, impedindo que seja alterada temporariamente – ela só pode ser lida.

    O que é distribution key

    Uma distribution key ou chave de distribuição é uma coluna (ou grupo de colunas) usada para determinar a partição do banco de dados em que um registro, em particular, será armazenado.
    Você define uma distribution key em uma tabela através do comando CREATE TABLE.

    
    ANALYZE TABLE projetos;
    
    +-------------------+---------+----------+-----------------------------+
    | Table             | Op      | Msg_type | Msg_text                    |
    +-------------------+---------+----------+-----------------------------+
    | clientes.projetos | analyze | status   | Table is already up to date |
    +-------------------+---------+----------+-----------------------------+
    1 row in set (0.01 sec)
    
    

    Optimize table

    Se você executa muitas operações de remoção de registros (DELETE), provavelmente precisará da declaração OPTIMIZE TABLE para fazer uso de espaços liberados e desfragmentar o arquivo de dados.

    
    OPTIMIZE TABLE projetos;
    
    +-------------------+----------+----------+----------+
    | Table             | Op       | Msg_type | Msg_text |
    +-------------------+----------+----------+----------+
    | clientes.projetos | optimize | status   | OK       |
    +-------------------+----------+----------+----------+
    1 row in set (0.04 sec)
    

    Como verificar e consertar seu sistema de arquivos no Ubuntu

    O sistema de arquivos do seu HD pode ter problemas, pelas mais variadas razões. Este artigo é sobre como checar e, se houver erros, corrigi-los, com o comando fsck.
    Uma situação típica, em que podem ocorrer, não somente perda de dados, mas danos ao seu sistema de arquivos é a situação de falta de energia.
    Você reinicia o sistema e ele pára, pedindo para que você faça o reparo manualmente do seu sistema de arquivos.

    Como usar o fsck para reparar o sistema de arquivos

    O fsck (file system consistency check — verificação da consistência do sistema de arquivos) é um programa usada para encontrar erros no sistema de arquivos e corrigi-los.
    Enquanto ferramenta de manutenção da integridade dos seus dados, é bom usá-la com frequência – especialmente em caso de o seu sistema ser desligado de forma irregular.
    Para usar o fsck, em um ambiente seguro, tal como vou descrever aqui, você precisará ter privilégios administrativos.
    O comando pode ser executado, como root, sozinho:

    fsck

    Nestas condições, ele irá perscrutar todas as partições descritas em /etc/fstab.
    O modo certo de usar o fsck, contudo, é no Runlevel 1, o modo monousuário. Neste runlevel, o seu PC pode se tornar indisponível para o ambiente gráfico – é o equivalente ao modo de segurança no Windows.
    Para reiniciar o sistema no runlevel 1, execute o seguinte comando:

    init 1

    em, seguida, desmonte a partição em que o fsck será executado.
    Se quiser obter uma lista das partições que se encontram montadas e onde estão montadas no seu sistema, use o comando:

    cat /etc/mtab

    ou para saber exatamente onde está montada a sua partição /home:

    cat /etc/mtab | grep home
    /dev/sda3 /home ext3 rw 0 0

    (vou usar a partição /dev/sda3, neste exemplo):

    umount /dev/sda3

    ou pelo seu nome:

    umount /home

    Agora execute o fsck:

    fsck /dev/sda3

    Se preferir não ter que responder a todas as perguntas feitas pelo fsck, use o modo -y. Assim, o fsck executará a verificação e aplicará as correções necessárias, sem te importunar com questões técnicas:

    fsck -y /dev/sda3

    Se houver arquivos danificados e estes forem recuperados pelo fsck, ele os guardará no diretório /home/lost+found
    Ao terminar o processo, você pode reiniciar o computador ou apenas montar de volta a partição desmontada:

    mount /home

    E volte ao runlevel multiusuário:

    init 2

    Simples, assim.

    LEIA TAMBÉM

    MySQL: Otimize suas consultas com Query Cache

    O QUERY CACHE armazena o texto de uma declaração SELECT junto ao seu resultado, no cliente. Quando uma declaração idêntica é recebida, mais tarde, o servidor apresenta o resultado, já pronto, em vez de fazer o trabalho de pesquisa novamente.
    O query cache é compartilhado entre sessões e, portanto, pode ser aproveitado por diversos outros clientes.

    Quando o Query Cache pode ser útil?

    Imagine um ambiente em que haja múltiplas tabelas, que não sofram muitas mudanças, para as quais o servidor receba várias consultas idênticas. Em uma situação como esta, é mais rápido fornecer a resposta pronta do que pesquisar a mesma coisa várias vezes.
    O query cache não retorna dados velhos ou vencidos. Quando as tabelas são alteradas, qualquer entrada relevante no query cache é descartada.
    Até as versões atuais do MySQL, há certas limitações:

    • O query cache não funciona em ambiente onde haja múltiplos servidores mysqld atualizando tabelas MyISAM.
    • O query cache não suporta tabelas particionadas e é automaticamente desabilitado nestes casos. Você não pode habilitá-lo nestes casos.

    O query cache não é “ciência exata” e sua eficiência pode variar em função da carga de trabalho a que o servidor está submetido.

    Como funciona o Query Cache?

    Antes de serem executadas, os textos das consultas são comparados aos que já se encontram armazenados no query cache, que é sensível à caixa. Portanto:

    SELECT * FROM nome_da_tabela
    select * from nome_da_tabela

    são duas queries diferentes.
    As consultas têm que ser exatamente as mesmas (em cada byte) para serem reconhecidas como idênticas.
    Há outros casos em que queries, mesmo idênticas, serão consideradas diferentes:

    • quando usarem bancos de dados diferentes;
    • ao usarem versões divergentes de protocolo;
    • ao ter diferentes default character set.

    O cache vai armazenar as queries, inseridas nos casos acima, separadamente.
    O cache não vai aceitar queries dentro das seguintes condições:

    • se refere a uma função definida por usuário — User Defined Function ou UDF;
    • em que sejam executadas de dentro de uma stored function, uma trigger ou um evento;
    • se refere a variáveis definidas por usuário ou programas locais;
    • se refere às tabelas dentro dos bancos de dados MySQL, INFORMATION_SCHEMA ou performance_schema;
    • não usa tabelas;
    • usa tabelas temporárias;
    • gera avisos;
    • o usuário não tem privilégios suficientes para sua completa execução;

    Agora, que já terminei de explicar como o query cache não funciona, vou tentar explicar aonde ele vai funcionar – o que é bem mais simples.
    Antes de entregar o resultado de uma query, o MySQL verifica se o usuário tem privilégios de SELECT referentes aos bancos de dados e tabelas envolvidos. Se não, o resultado armazenado no cache não poderá ser usado.
    O query cache também funciona entre transações, quando você estiver usando tabelas InnoDB.
    A partir da versão 5.7 do MySQL, o resultado de uma consulta SELECT em uma VIEW será armazenada no cache.

    Como configurar

    É possível configurar o valor do query cache

    • no terminal do seu sistema, com o comando mysqld;
    • no arquivo de configuração my.cnf (permanentemente);
    • no cliente do MySQL.

    Neste texto, vou mostrar como configurar o query cache direto no cliente MySQL. Abra um terminal e autentique-se no servidor:

    mysql -u root -p

    Dentro do MySQL, verifique se o query cache está disponível:

    SHOW VARIABLES LIKE 'have_query_cache';
    +------------------+-------+
    | Variable_name    | Value |
    +------------------+-------+
    | have_query_cache | YES   |
    +------------------+-------+
    1 row in set (0.00 sec)

    Para a gente pode brincar, aqui, o valor da variável have_query_cache precisará ser igual a YES, mesmo que o query cache esteja desativado.
    Dentro do MySQL ajuste o tamanho do query cache através da definição da variável de sistema query_cache_size:

    SET GLOBAL query_cache_size = 40000

    Para desabilitar a função, ajuste o valor de query_cache_size para 0. Seja cuidadoso com o tamanho total da variável. As threads precisam trancar o cache durante sua atualização — caches muito grandes ficam mais tempo trancados.

    Textos relacionados:
    • O comando SELECT — conheça várias dicas de uso do comando, no MySQL.
    • Data types — os tipos de dados possíveis para criar campos em uma tabela.
    • Storage engines — conheça os mecanismos de armazenamento do MySQL.

    Que tamanho usar pro query cache

    O manual do MySQL adverte que o tamanho mínimo possível para query_cache_size é 40Kb, para que ele possa alocar suas estruturas.
    Já o tamanho adequado depende da arquitetura do seu sistema. Como já foi dito, valores muito altos podem causar mais prejuízos do que benefícios — uma vez que aumentam o tempo em que o cache fica indisponível a cada atualização.
    Valores muito pequenos podem causar a exibição de uma mensagem de aviso e o desativamento do query cache. Veja:

    SET GLOBAL query_cache_size = 40000;
    Query OK, 0 rows affected, 2 warnings (0.01 sec)
    SHOW WARNINGS\G
    *************************** 1. row ***************************
      Level: Warning
       Code: 1292
    Message: Truncated incorrect query_cache_size value: '40000'
    *************************** 2. row ***************************
      Level: Warning
       Code: 1282
    Message: Query cache failed to set size 39936;
    new query cache size is 0
    2 rows in set (0.01 sec)

    Na última linha da mensagem, o sistema avisa que alterou o valor da variável query_cache_size para 0.
    Neste caso, você deve aumentar gradualmente o valor da variável e testar o seu sistema por alguns dias.
    O manual da versão 5.7 do MySQL recomenda um valor mínimo de 1000000, para que o query cache consiga guardar um número razoável de resultados de consultas.

    screenshot mysql set global query_cache_size
    Clique para ampliar