Consulta lenta para a tabela wp_options

Atualização : O motivo pelo qual a consulta está sendo registrada é não usa um índice . O tempo de consulta é 0, ou seja, ele é executado de maneira rápida. Você pode desconfigurar a opção "log-queries-não-usando-índices" se você não quiser que estes sejam registrados.

A tabela wp_options não possui índice no carregamento automático, portanto, a consulta acaba fazendo uma varredura completa da tabela. Em geral, essa tabela não deve ficar muito grande, então não é um problema, mas acho que de alguma forma isso aconteceu no seu caso.

Adicionar um índice pode resolver o problema, mas como TheDeadMedic apontou nos comentários, pode ser que os valores de autoload sejam maioritariamente sim ou distribuídos uniformemente entre sim e não:

Primeiro, faça essa consulta para ver como é a distribuição:

SELECT COUNT(*), autoload FROM wp_options GROUP BY autoload;

se a grande maioria deles estiver configurada como 'no', você poderá resolver o problema adicionando um índice no autoload.

ALTER TABLE wp_options ADD INDEX ('autoload');

No entanto, você pode querer entender por que essa tabela ficou muito grande. Possivelmente algum plugin mal escrito fazendo algo suspeito.

Eu tropecei na consulta mencionada no mytop em execução no meu servidor alguns dias atrás - e na verdade levou algum tempo (cerca de 10 segundos) para cada consulta! Portanto, há situações do mundo real em que as opções do wp podem aumentar para um tamanho problemático. No meu caso, suspeito que o plugin de cache Cachify seja responsável pelo inchaço das wp_options.

Dados desta wp_options em particular:

5,309 rows
130MB of data

Como solução, adicionei o índice semelhante à solução publicada por Vinay Pai, que resolveu o problema sem problemas.

Minha tabela wp_options tinha apenas cerca de 235 linhas de dados. Eu tentei indexar a tabela, mas isso não ajudou.

Acontece que cerca de 150 opções transitórias foram inseridas na tabela, mas não foram excluídas automaticamente.

Eu não sei se está relacionado ou não, mas eu estava olhando através dos meus arquivos /var/log/apache2/access.log e notei que vários servidores (supostamente comprometidos) da Amazon Web Services (endereços IP começando com 54.XXX e 32.XXX) estava tentando explorar o /~web-root-dir/xmlrpc.php.

Após algumas soluções de problemas, consultei a tabela wp_options para nomes de opções que continham "transitório"

selecione * de wp_options onde option_name como '% transiente %';

Um dos campos retornados dessa consulta é 'option_value' que possui um tipo de dados de LONGTEXT. De acordo com os documentos mySQL, um campo LONGTEXT (para cada linha) pode conter até 4 gigabytes de dados.

Quando eu executei a consulta, algumas das linhas (lembre-se que estavam trabalhando com as que continham "transientes") tinham quantidades massivas de dados no campo option_value. Analisando os resultados, também vi o que pareciam tentativas de injetar comandos no processo wp-cron com as esperanças de que eles seriam executados durante o (s) ciclo (s) do cronômetro.

Minha solução foi excluir todas as linhas "transitórias". Isso não afetará o servidor, pois as linhas "transitórias" serão repovoadas automaticamente (se supostamente estiverem lá).

Depois de fazer isso, o servidor voltou a responder.

Consulta para excluir essas linhas:

DELETE de wp_options onde option_name como '% transiente %';

Também adicionei o endereço IP da AWS / 8 superblocos ao meu firewall (-: