Query folding no Power Query: valide a execução real
O query folding no Power Query é a tradução de transformações para operações executadas pela fonte de dados. Também chamado de dobramento de consulta, ele pode reduzir o trabalho feito no mecanismo local. Sua existência depende do conector, da fonte e das transformações utilizadas.
Este roteiro investiga uma carga de vendas conectada a um banco com capacidade de consulta. O objetivo é verificar o que foi executado na origem, comparar alternativas e preservar o resultado. Uma transformação rápida na prévia não comprova que a carga completa usa o mesmo caminho de execução.
1. Defina o cenário do query folding no Power Query
Registre fonte, conector, modo de conexão e resultado esperado. A visão geral da Microsoft, atualizada em 20 de agosto de 2026 e consultada em 7 de outubro, distingue execução totalmente dobrada, parcialmente dobrada e sem dobramento. Não classifique toda a consulta a partir de uma única etapa.
Para o exemplo hipotético, a origem é uma tabela de vendas num banco SQL e a análise precisa apenas dos últimos três meses. O teste procura verificar se o filtro de período e a seleção de colunas chegam à fonte, mantendo os mesmos registros do processo original.
2. Registre uma linha de base antes de mudar etapas
Guarde uma cópia da consulta, o período selecionado, a quantidade de linhas e totais de referência. Anote a duração da operação que será comparada, como atualização da prévia ou carga do modelo. Essas operações não devem ser tratadas como medições equivalentes.
Mantenha as condições do teste próximas: mesma fonte, filtros, volume e ambiente. Em um exemplo hipotético, comparar uma carga em horário de baixa demanda com outra durante um processo pesado no banco não isola o efeito da mudança no Power Query.
3. Inspecione a consulta enviada à fonte
Quando a opção estiver disponível, use Exibir Consulta Nativa para examinar a solicitação correspondente à etapa. Procure a restrição de período e as colunas necessárias. A disponibilidade desse recurso depende do conector; a documentação de visão geral descreve essa condição.
Não use apenas o estado do botão como relatório de diagnóstico. Se não conseguir visualizar a consulta, busque evidência no diagnóstico ou com a equipe responsável pela fonte. O importante é demonstrar onde a transformação ocorreu e quais dados foram solicitados.
4. Avalie filtros e colunas que reduzem o trabalho
Teste aplicar o recorte necessário e remover colunas não utilizadas antes de transformações mais complexas, quando isso preservar a lógica. No cenário hipotético, o relatório precisa de data, cliente, produto, quantidade e valor. Trazer descrições extensas sem uso aumenta o material processado sem acrescentar informação.
Confira se a solicitação enviada à fonte mudou conforme a hipótese. Ter uma etapa de filtro visível no editor não demonstra, sozinho, onde ela foi executada. Compare também o resultado final: a otimização não pode excluir registros que a regra de negócio exige manter.
5. Localize etapas que exigem processamento adicional
Percorra a sequência e observe como a evidência muda depois de cada transformação. Uma consulta pode executar filtros na fonte e realizar outra etapa no mecanismo local. Registre essa fronteira em vez de concluir que perder dobramento completo tornou todas as etapas anteriores inúteis.
Use os exemplos oficiais de query folding, consultados em 7 de outubro de 2026, como referência de investigação. No seu projeto, teste a operação concreta e o conector utilizado. Não suponha que uma lista genérica de transformações reproduz o comportamento de qualquer fonte.
6. Não aplique Table.Buffer como correção automática
A função Table.Buffer coloca uma tabela em memória. A referência da Microsoft, consultada em 7 de outubro de 2026, informa que ela pode aumentar o tempo e impedir dobramento nas etapas seguintes. Sua presença exige uma razão técnica e uma comparação específica.
Se alguém sugerir adicioná-la, registre a hipótese que ela pretende resolver. Faça o teste numa cópia e compare duração, resultado e solicitações à origem. Não acumule buffers, mudanças de ordem e filtros numa única tentativa, pois ficará difícil identificar qual alteração mudou o comportamento.
7. Use diagnóstico para reunir evidências
O recurso de Diagnóstico de Consulta fica na guia Ferramentas do editor, conforme a documentação oficial, consultada em 7 de outubro de 2026. Inicie a captura, execute uma ação delimitada e interrompa o diagnóstico para obter os registros da avaliação.
Separe a ação investigada de consultas de metadados, prévias e outras atividades do editor. A documentação também observa efeitos de cache ao comparar etapas. Se houver dúvida sobre os registros, guarde a captura e examine-a com o responsável pela fonte, preservando informações sensíveis de conexão.
8. Confirme equivalência após reorganizar a consulta
Compare linhas, chaves, nulos, tipos e totais da versão original com a candidata. Mudar a ordem de filtragem e limpeza pode alterar quais linhas passam pelo filtro. Por exemplo, um valor textual convertido para data depois da seleção pode se comportar diferente de uma data já padronizada.
O roteiro de mesclagem sem duplicar vendas ajuda a conferir etapas de enriquecimento. Caso a consulta use junções, teste chaves repetidas e sem correspondência. Preservar a contagem total não basta quando os registros associados podem ter mudado.
9. Diferencie carga de dados e resposta dos visuais
Uma melhora no processo de preparação não resolve necessariamente a lentidão ao clicar num relatório já carregado. A análise de Performance Analyzer atende ao diagnóstico dos visuais. Identifique a etapa do problema antes de escolher a ferramenta e interpretar a medição.
Se o tempo continuar elevado, verifique o trabalho que permanece na fonte e no mecanismo local. Encaminhe a consulta ao responsável pelo banco quando for necessário investigar sua execução. Não prometa ganho percentual universal: informe o resultado observado nas condições documentadas do teste.
Se a alternativa retornar dados diferentes, suspenda a comparação de velocidade e localize primeiro a divergência. Guarde as chaves presentes só em cada versão e revise os filtros envolvidos. Uma carga menor porque perdeu vendas pode parecer mais rápida, mas não atende ao objetivo da análise.
10. Libere a alteração com evidências de resultado
Registre versão da consulta, hipótese, evidência de execução, duração e conferência funcional. Repita os casos de fronteira, como datas no limite do período e registros sem cadastro. Uma alteração só deve substituir a versão em uso quando o resultado permanecer coerente e o benefício fizer sentido para a operação.
O modelo editável de Vendas pode ser conectado a uma base preparada conforme suas necessidades. O dobramento depende da fonte e das consultas implementadas no projeto. Comece por uma carga delimitada, documente o caminho real de execução e mantenha uma versão anterior para comparar futuras regressões.
Na manutenção, repita a verificação quando o conector, a fonte ou uma transformação mudar. Guarde pelo menos um caso com resultado conhecido e o registro da solicitação à origem. Assim, a equipe consegue distinguir uma mudança no processamento de uma diferença normal no volume de dados.