🎉 USE O CUPOM DESCONTO.FULL | 20% OFF acima de R$ 50,00

Como corrigir as queries lentas do JetEngine no banco de dados

Time Full Services Time Full Services
Tipo Performance & Velocidade
Nome do erro Queries lentas do JetEngine no banco de dados EN: JetEngine slow database queries
Severidade Grave
Descrição As queries lentas do JetEngine acontecem quando uma query do Query Builder executa Meta Query ou SQL pesado em toda requisicao sem cache, fazendo o Listing Grid demorar e o banco devolver tempos altos. Costuma vir de Meta Query sem indice, Cache Query desligado, SQL com varredura completa e falta de cache de objetos.

O que é as queries lentas do JetEngine no banco?

As queries lentas do JetEngine no banco são consultas montadas pelo Query Builder que demoram muito para retornar e seguram a renderizacao do Listing Grid, do Dynamic Table ou do Map Listing. O Query Builder e a ferramenta do JetEngine, em JetEngine -> Query Builder, que monta a consulta ao banco (Posts Query, Terms Query, Users Query, SQL Query, entre outras) e entrega o resultado ao widget. Quando essa query filtra por muitos campos de metadados, usa SQL que varre a tabela inteira ou roda sem o Cache Query ligado, cada visita a página obriga o MySQL a refazer o trabalho, o tempo de resposta sobe e o TTFB da página dispara.

Como identificar

  • A página com o Listing Grid do JetEngine leva vários segundos para abrir, enquanto outras páginas do mesmo site respondem rápido.
  • O Query Monitor lista a query do JetEngine entre as Slowest Queries, com tempo acima de meio segundo e a clausula com JOIN na tabela wp_postmeta.
  • Com o slow query log do MySQL ligado, a consulta do Listing aparece registrada por ultrapassar o long_query_time configurado.
  • O Listing Grid com paginação fica mais lento a cada página, e os filtros do JetSmartFilters demoram para aplicar.
  • Com muitos acessos simultaneos, o uso de CPU do MySQL sobe e o host aponta limite de processos do banco atingido.
Antes de começar: Antes de criar indice, alterar tabela ou mexer em variaveis do MySQL em producao, faca backup completo do site e do banco de dados. Criar indice em tabela grande bloqueia gravacao por alguns instantes e uma alteração errada pode derrubar o banco. Teste em ambiente de staging antes de aplicar no site no ar.

Como prevenir

  • Mantenha o Cache Query ligado nas queries do Query Builder e so desative quando a query realmente precisar de dado sempre atualizado
  • Prefira Posts Query com poucos filtros de Meta Query a uma SQL Query manual, e quando usar SQL garanta indice na coluna do filtro
  • Use paginação e um Posts Per Page moderado no Listing Grid em vez de carregar centenas de registros de uma vez
  • Monitore as páginas com Listing Grid pelo Query Monitor e pelo slow query log, agindo assim que uma query passar de meio segundo
  • Mantenha um cache de objetos persistente (Redis ou Memcached) ativo para servir os resultados da query da memória

Causa

  • Uma Meta Query do Query Builder filtrando por vários campos de metadados gera múltiplos JOIN na tabela wp_postmeta, que não tem indice em meta_value, forcando o MySQL a varrer milhares de linhas por requisicao.
  • O toggle Cache Query da query, ligado por padrão, foi desativado no Query Builder, entao o JetEngine reexecuta a consulta inteira no banco a cada carregamento da página em vez de reaproveitar o resultado.
  • Uma query do tipo SQL Query escrita sem clausula WHERE seletiva ou sem indice na coluna usada no filtro, fazendo o banco ler a tabela inteira (full table scan) para montar o Listing.
  • Posts Per Page alto ou ausencia de paginação no Listing Grid, pedindo centenas de registros de uma vez e inflando o conjunto de dados que o banco precisa ordenar e devolver.
  • Ausencia de cache de objetos persistente (Redis ou Memcached), obrigando o banco a refazer a query do Query Builder a cada visita em vez de servir o resultado da memória.
  • Relations Query ou Meta Query com ordenacao por um meta field não indexado, fazendo o MySQL montar uma tabela temporaria e ordenar em disco a cada requisicao.

Como resolver

  1. Confirme qual query do Query Builder esta lenta: instale o Query Monitor e abra a página lenta. Na aba de banco, ordene por tempo e identifique a consulta do JetEngine que aparece entre as mais lentas e a tabela que ela toca, geralmente wp_posts com JOIN em wp_postmeta. Isso confirma que o gargalo e a query do Listing, e não outra coisa.
    WP Admin -> Plugins -> instalar e ativar Query Monitor
    Abrir a página lenta -> Query Monitor -> Queries -> Slowest -> localizar a query do JetEngine
  2. Garanta que o Cache Query da query esteja ligado: abra a query no Query Builder e confirme que o switcher Cache Query, ligado por padrão, não foi desativado. Com ele ligado, o JetEngine reaproveita o resultado em vez de refazer a consulta a cada carregamento. So mantenha desligado se a query precisa de dado sempre fresco.
    WP Admin -> JetEngine -> Query Builder -> abrir a query -> General Settings -> Cache Query (ON)
  3. Reduza a Meta Query e a quantidade de itens por página: abra as condicoes da query e remova os filtros de Meta Query que não são essenciais, pois cada um adiciona um JOIN na wp_postmeta. No widget, baixe o Posts Per Page e ligue a paginação para o banco devolver menos linhas por requisicao.
    WP Admin -> JetEngine -> Query Builder -> abrir a query -> Meta Query -> remover condicoes não essenciais
    Editor -> Listing Grid -> Settings -> Posts Per Page -> reduzir o número
    Editor -> Listing Grid -> ligar paginação
  4. Meça a query no slow query log e leia o plano de execução: ative o slow query log do MySQL para capturar a consulta lenta e rode um EXPLAIN sobre ela. O plano mostra se o banco esta fazendo varredura completa (type ALL) e qual coluna precisaria de indice. So depois disso você sabe onde criar o indice em vez de adivinhar.
    SET GLOBAL slow_query_log = 'ON';
    SET GLOBAL long_query_time = 0.5;
    EXPLAIN SELECT ... ;
  5. Crie um indice para a coluna filtrada na SQL Query: quando a query e do tipo SQL Query e o EXPLAIN apontou varredura completa, adicione um indice na coluna usada no filtro ou na ordenacao da sua tabela. Faca isso com backup do banco, porque criar indice em tabela grande bloqueia escrita por alguns instantes.
    ALTER TABLE wp_minha_tabela ADD INDEX idx_campo (campo);
  6. Ative um cache de objetos persistente: configure Redis ou Memcached como cache de objetos do WordPress. Com ele, o resultado da query do Query Builder fica em memória e e servido sem bater no banco a cada visita, o que corta o tempo de resposta nas páginas com Listing Grid.
    WP Admin -> Plugins -> ativar o plugin de Redis Object Cache do seu host
    WP Admin -> Settings -> confirmar Object Cache: Connected
SQL
-- 1) Ligar o slow query log para capturar as consultas do JetEngine que demoram
--    mais de 0,5s (rode no banco; em producao prefira via my.cnf):
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 0.5;

-- 2) Plano de execucao de uma Meta Query tipica do Listing Grid.
--    type = ALL e rows altíssimo indicam varredura completa por falta de indice:
EXPLAIN
SELECT p.ID
FROM wp_posts AS p
INNER JOIN wp_postmeta AS pm ON ( p.ID = pm.post_id )
WHERE p.post_type = 'meu_cpt'
  AND p.post_status = 'publish'
  AND pm.meta_key = 'preco'
  AND pm.meta_value > '1000'
ORDER BY pm.meta_value + 0 ASC;

-- 3) Quando a query e do tipo SQL Query sobre tabela propria, criar indice na
--    coluna do filtro/ordenacao remove a varredura completa (troque pelos nomes reais):
ALTER TABLE wp_minha_tabela ADD INDEX idx_campo (campo);

Perguntas frequentes

Por que o Listing Grid do JetEngine ficou lento de repente?
Quase sempre a query por tras dele passou a filtrar por mais campos de Meta Query, teve o Cache Query desligado, ou a tabela cresceu e o banco passou a varrer mais linhas. Abra o Query Monitor na página lenta, identifique a consulta do JetEngine entre as mais lentas e confirme se ela faz JOIN pesado na wp_postmeta.
O que e o Cache Query no Query Builder do JetEngine?
E um switcher das configurações da query, ligado por padrão, que faz o JetEngine guardar o resultado e reaproveita-lo em vez de refazer a consulta a cada carregamento. A própria documentação recomenda desliga-lo apenas quando ha problemas com o resultado da query. Mante-lo ligado costuma reduzir bastante o tempo de resposta.
Por que a Meta Query do JetEngine deixa a consulta lenta?
Cada condicao de Meta Query adiciona um JOIN na tabela wp_postmeta, que não tem indice na coluna meta_value. Com várias condicoes e muitos posts, o MySQL precisa varrer milhares de linhas por requisicao. Reduzir o número de filtros de metadado e limitar os itens por página diminui o trabalho do banco.
Como descubro qual query do JetEngine esta pesando no banco?
Use o Query Monitor para ver as consultas mais lentas da página e ligue o slow query log do MySQL para registrar as que passam do tempo limite. Depois rode um EXPLAIN sobre a consulta: se o plano mostrar type ALL e muitas linhas lidas, o banco esta fazendo varredura completa por falta de indice.
Criar indice resolve a query lenta de uma SQL Query?
Resolve quando o EXPLAIN aponta varredura completa numa coluna usada no filtro ou na ordenacao. Um indice nessa coluna deixa o MySQL achar as linhas direto, em vez de ler a tabela inteira. Faca com backup, porque criar indice em tabela grande bloqueia a gravacao por alguns instantes.
O cache de objetos ajuda nas queries do JetEngine?
Ajuda bastante. Com Redis ou Memcached ativos, o resultado da query do Query Builder fica em memória e e servido sem bater no banco a cada visita, reduzindo o tempo de resposta nas páginas com Listing Grid. Ainda assim, convem enxugar a Meta Query, porque o cache guarda o que for pedido, inclusive a consulta pesada.
Posso resolver tudo pelo painel ou preciso mexer no banco?
Boa parte resolve pelo painel: ligar o Cache Query, reduzir a Meta Query, baixar o Posts Per Page e ativar o cache de objetos. So e preciso ir ao banco para ligar o slow query log, rodar o EXPLAIN e criar indice quando a query e do tipo SQL Query sobre uma tabela própria com varredura completa.

Seja PRO.

Tenha acesso a snippets de código premium — PHP, JavaScript, CSS e HTML prontos para usar em seus projetos.

Conhecer o plano Pro →

Uma nova era para o WordPress.

A FULL Services redefine o CMS com uma arquitetura modular que transforma o WordPress em um motor de crescimento digital. 

Painéis personalizados

Um novo nível de controle para o WordPress. Acompanhe métricas, automações e evolução do seu site em um único painel visual.

A força por trás de grandes marcas

Para agências, estúdios e profissionais independentes que desejam oferecer soluções de alto nível com sua própria marca.

Componentes

Hero Sections

30 componentes

Seções de CTA

14 componentes

Login

14 componentes

Blog

14 componentes

Cabeçalhos

24 componentes

Seções de FAQ

53 componentes

Cadastro

53 componentes

Blog individual

53 componentes

Rodapés

28 componentes

Seções de contato

27 componentes

Seções de preços

27 componentes

Faixas

27 componentes

Portfólio

16 componentes

Seções de equipe

12 componentes

Números

12 componentes

Logotipos

12 componentes