Consulta lenta para a tabela wp_options


16

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).

Respostas:


16

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.


2
Duvido que um índice nesse caso ofereça algum ganho - confira este artigo sobre cardinalidade .
TheDeadMedic #

Depende se a maioria das opções está configurada para carregamento automático ou não. Eu acho que não, mas na tabela nunca deve ficar tão grande assim, então algo suspeito está acontecendo.
Vinay Pai6 /

1
Eu atualizei por resposta para adicionar um pouco sobre como verificar a distribuição de valores.
Vinay Pai #

1
Acabei de notar o comentário e percebi que minha resposta está completamente errada. A consulta não é realmente lenta ... está apenas sendo registrada no log de consultas lentas porque não usa um índice.
Vinay Pai

1
Graças a esta pergunta e resposta, descobri que tinha 90 mil entradas na minha tabela wp_options, das quais 88,5 mil foram definidas para carregamento automático de falso. O restante foram todas as entradas "transitórias" adicionadas pelos plug-ins (presumivelmente para armazenamento em cache?). A adição de um índice à coluna de carregamento automático reduziu minha carga do mySql de uma média de 89% para 2,5% instantaneamente. Os agentes de monitoramento mostram que o tempo de resposta do meu site caiu de 1900ms para 500ms. Este foi um trocador de jogos para mim.
Mordred

5

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.


1

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 (-:


Sim. Eu também sofria com "40 segundos de tempo de carregamento" até descobrir que tinha 20.000 registros wp_option com dados maciços sendo carregados em todas as páginas. Remover aqueles consideravelmente acelerou o site.
JasonGenX 12/02/19
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.