Consulta lenta para a tabela wp_options

Tenho rastreado o log de consultas lentas do site baseado no WP (com o valor padrão de um long_query_time definido como 10) e notei que a consulta a seguir geralmente está sendo registrada -

# User@Host: root[root] @ localhost []
# Query_time: 0  Lock_time: 0  Rows_sent: 394  Rows_examined: 458
SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes';

Eu não entendo como uma tabela tão pequena pode levar tanto tempo para ser executada. Isso é apenas um sintoma de algum outro problema? (Atualmente executando o Moodle, phpbb e WP em uma VM dedicada).

Atualização : o motivo pelo qual a consulta está sendo registrada é que ela não usa um índice . O tempo de consulta é 0, ou seja, ele é executado rapidamente. Você pode desmarcar a opção "consultas de log que não usam índices" se não quiser que elas sejam registradas.

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, por isso não é um problema, mas acho que isso aconteceu de alguma forma no seu caso.

Adicionar um índice pode resolver o problema, mas, como TheDeadMedic apontou nos comentários, talvez não, se os valores de carregamento automático forem maioria sim ou distribuídos igualmente entre sim e não:

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

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

se uma grande maioria deles estiver definida como 'não', você poderá resolver o problema no momento adicionando um índice no carregamento automático.

ALTER TABLE wp_options ADD INDEX (`autoload`);

No entanto, convém entender por que essa tabela ficou muito grande. Possivelmente algum plugin mal escrito fazendo algo suspeito.

Eu me deparei com a consulta mencionada no mytop em execução no meu servidor há 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 wp_options pode crescer para um tamanho problemático. No meu caso, suspeito que o plug-in de cache Cachify seja responsável por inchar o wp_options.

Dados deste wp_options específico:

5,309 rows
130MB of data

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

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

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

Não sei se ele está relacionado ou não, mas estava procurando nos meus arquivos /var/log/apache2/access.log e notei que vários servidores Amazon Web Services (presumivelmente comprometidos) (endereços IP começando com 54. XXX e 32.XXX) estavam tentando explorar /~web-root-dir/xmlrpc.php.

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

selecione * de wp_options em que option_name como '% transient %';

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

Quando eu executei a consulta, algumas das linhas (lembre-se de trabalhar com as que contêm "transitório") tinham grandes quantidades de dados no campo option_value. Examinando os resultados, também vi tentativas de injetar comandos no processo wp-cron com a esperança de que eles fossem executados durante o (s) ciclo (s) cron (s).

Minha solução foi excluir todas as linhas "transitórias". Isso não prejudicará o servidor, pois as linhas "transitórias" serão automaticamente preenchidas novamente (se elas deveriam estar lá).

Depois disso, o servidor voltou a responder.

Consulta para excluir estas linhas:

DELETE de wp_options em que option_name como '% transient %';

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