É 'query_posts' muito mais lento que a consulta secundária?

3

Eu sei que a consulta principal é rápida, pois obtém dados após a análise da URL e depois que WP_Query foi instanciado. Estamos em OO PHP.

Mas é query_posts realmente mais lento do que alguma consulta secundária que acontece em um modelo, por exemplo, com get_posts ou nativo chamado com

// WP_Query arguments
$args = array (
);

// The Query
$query = new WP_Query( $args );
    
por prosti 19.05.2016 / 22:32

2 respostas

7

Você pergunta:

  

é query_posts muito mais lento que alguma consulta secundária ...

O fato é que, se você estiver chamando query_posts() de um tema, então, ele já é uma consulta secundária . O WordPress já consultou o banco de dados uma vez para obter uma certa página, então ele atinge sua função query_posts() e consulta o banco de dados novamente criando uma segunda consulta e sobrescrevendo a solicitação / dados original .

De uma perspectiva de velocidade, você não vai notar nenhuma diferença. A função query_posts() usa WP_Query() e toma microssegundos para sobrescrever algumas variáveis globais. A maior sobrecarga virá de você ter que normalizar seus dados e compensar qualquer problema de nicho com paginação.

Simplificando, é tudo ineficiente. Então, enquanto não pode haver um "grande botão vermelho" que diz "Não pressione aqui!" é praticamente implícito que não deve ser pressionado. Não é grande e vermelho, mas O Codex afirma especificamente :

  

Observação: essa função não deve ser usada por plug-ins ou temas.

Se você quiser ser eficiente e precisar substituir a consulta principal, use pre_get_posts que modificará os parâmetros de consulta antes de chamá-los do banco de dados que salva uma chamada de banco de dados inteira (no qual não precisamos de uma consulta secundária).

    
por Howdy_McGee 19.05.2016 / 23:02
3

Em geral,

  • a consulta realizada na página inicial,

  • query_posts( 'posts_per_page=get_option( 'posts_per_page' ) e

  • $q = new WP_Query( 'posts_per_page=get_option( 'posts_per_page' )

deve ter o mesmo desempenho exato com muito pouca ou nenhuma diferença entre eles, já que todos os itens acima são exatamente os mesmos por padrão ( isto é, tem os mesmos argumentos de consulta por padrão ). Isso ocorre porque todas essas consultas usam a classe WP_Query para executar consultas build e run do banco de dados para retornar as postagens consultadas. get_posts() é um pouco mais rápido, embora também use WP_Query . A grande diferença é que get_posts passa no_found_rows=true para WP_Query , o que legalmente quebra a paginação.

O que é verdade, a consulta principal ( consulta primária ) é executada em cada carregamento de página de acordo com a página exata que está sendo carregada. Remover o loop principal e substituí-lo por uma consulta secundária ( query_posts() , WP_Query ou get_posts() ) é o que é referido como tornando a página lenta. Isso é porque você está fazendo o mesmo trabalho duas vezes. Como eu disse, a consulta principal é executada independentemente, então você já consultou o banco de dados para postagens, e substituir o loop principal por uma consulta secundária consulta o banco de dados novamente.

Além dos problemas criados com paginação e outros problemas de baixa qualidade, é por isso que é necessário nunca substituir o loop principal da consulta principal por um secundário. Eu fiz um extenso post sobre isso que você pode ler aqui . Para alterar a consulta principal, use sempre pre_get_posts , pois ela altera a consulta vars antes que a classe WP_Query construa e execute a consulta SQL. Existem também outros filtros ( filtros de cláusula post ) disponíveis em WP_Query , que você pode usar para alterar diretamente a consulta SQL

O que torna query_posts bad é que ele altera o objeto de consulta principal no qual muitas funções dependem, pois query_posts faz o seguinte

$wp_query = new WP_Query()

e também altera as tags condicionais. Para uma explicação completa, você pode ler minha resposta aqui . Um% normalWP_Query não faz isso

    
por Pieter Goosen 20.05.2016 / 06:33