VAR (variáveis) em DAX: o que faz e quando usar (com exemplos)

Medidas ilegíveis e lentas quase sempre têm a mesma causa#

Se você já abriu uma medida herdada de outra pessoa e encontrou a mesma expressão CALCULATE repetida quatro vezes dentro de um DIVIDE, você já viu o problema que o recurso VAR (variáveis) DAX resolve. O código fica difícil de ler, difícil de auditar e, com frequência, mais lento do que precisaria ser. Variáveis não são um detalhe cosmético: elas mudam como o motor calcula a medida e como o próximo analista vai entender o que você escreveu.

Neste artigo vou direto ao ponto. Você vai ver a sintaxe correta, exemplos conceituais que aparecem em qualquer modelo real, as armadilhas de contexto que pegam quem está começando e as boas práticas que aplicamos em projetos de cliente. A ideia é que você saia daqui usando VAR por decisão técnica, não por moda.

O que VAR faz de verdade no motor DAX#

VAR declara uma variável dentro de uma expressão DAX. Você atribui um nome a um resultado e usa esse nome adiante, sempre acompanhado de um RETURN que define o valor final da medida ou coluna. A sintaxe básica é esta:

Medida =
VAR VendasTotais = SUM( Vendas[Valor] )
VAR VendasAno = CALCULATE( VendasTotais, ANO = 2026 )
RETURN
    DIVIDE( VendasAno, VendasTotais )

Dois pontos importam mais do que a estética. Primeiro, uma variável em DAX é constante: uma vez avaliada, o valor não muda no restante da expressão. Ela não é uma variável no sentido de linguagens imperativas, onde você reatribui valores em um laço. Pense nela como um apelido para um resultado já calculado.

Segundo, e é aqui que muita gente escorrega, a variável é avaliada no contexto de filtro e de linha existentes no momento e no local onde ela é declarada, não onde ela é usada. Isso é chamado de avaliação preguiçosa combinada com fixação de contexto: o DAX só calcula a variável se ela for realmente usada, mas quando calcula, congela o contexto do ponto de declaração. Guarde essa frase, porque metade dos bugs com variáveis nasce de ignorá-la.

Por que variáveis deixam a medida mais legível#

Legibilidade não é conforto, é manutenção. Uma medida que qualquer pessoa da equipe lê em trinta segundos custa menos para corrigir, evoluir e governar. Compare as duas formas de escrever um crescimento percentual ano contra ano.

Sem variáveis, a lógica se repete e o erro se esconde:

Crescimento % =
DIVIDE(
    SUM( Vendas[Valor] ) - CALCULATE( SUM( Vendas[Valor] ), DATEADD( Calendario[Data], -1, YEAR ) ),
    CALCULATE( SUM( Vendas[Valor] ), DATEADD( Calendario[Data], -1, YEAR ) )
)

Com variáveis, cada passo tem nome e a intenção fica explícita:

Crescimento % =
VAR VendasAtual = SUM( Vendas[Valor] )
VAR VendasAnterior = CALCULATE( VendasAtual, DATEADD( Calendario[Data], -1, YEAR ) )
VAR Diferenca = VendasAtual - VendasAnterior
RETURN
    DIVIDE( Diferenca, VendasAnterior )

A segunda versão diz o que faz. Um revisor confere se VendasAnterior está correta uma vez, não duas. E quando o requisito mudar, você altera um único ponto. Esse tipo de disciplina é o que separa um modelo que dura de um que vira dívida técnica, tema que tratamos em modelagem e boas práticas de DAX no Power BI.

Por que variáveis deixam a medida mais rápida#

Aqui entra o argumento de performance, e ele é concreto. Quando você repete CALCULATE( SUM( Vendas[Valor] ), ...) três vezes na mesma medida, o motor tende a avaliar aquela subexpressão mais de uma vez. Com uma variável, você calcula o resultado uma vez e reaproveita.

O DAX roda sobre dois motores. O Storage Engine, que no VertiPaq comprime as colunas em memória por cardinalidade e responde consultas de agregação de forma muito eficiente, e o Formula Engine, que orquestra a lógica e é single threaded para boa parte das operações. Cálculos repetidos e mal estruturados sobrecarregam o Formula Engine, geram varreduras extras e alongam o tempo de resposta do visual. Ao materializar um resultado em uma variável, você reduz reavaliações e dá ao otimizador uma estrutura mais limpa para trabalhar.

Um segundo ganho aparece dentro de IF. Considere:

Resultado =
VAR Total = [Vendas Complexas]
RETURN
    IF( Total > 1000000, Total * 0.9, Total )

Como Total é calculado uma vez, ele não é reavaliado no ramo verdadeiro e no falso. Sem a variável, dependendo de como você escreve, corre o risco de calcular a medida pesada duas vezes. A tabela abaixo resume onde está o ganho.

Situação	Sem VAR	Com VAR
Subexpressão usada várias vezes	Reavaliada a cada uso	Calculada uma vez
Ramos de IF	Risco de recalcular	Valor único reaproveitado
Leitura por outro analista	Depende de decifrar aninhamento	Passos nomeados
Depuração	Difícil isolar o passo com erro	Cada VAR isolável no RETURN

Vale um alerta honesto: variável não é bala de prata. Se o motor já reconhece a subexpressão idêntica, o ganho pode ser pequeno. A regra prática é medir. Use o Performance Analyzer no Power BI Desktop e, para quem quer ir a fundo, o DAX Studio para ler o plano de consulta e comparar antes e depois.

As armadilhas de contexto que mais pegam#

A vantagem das variáveis vira armadilha quando você esquece que o contexto é congelado na declaração. Este é o exemplo clássico que confunde quase todo mundo.

Ranking Errado =
VAR VendasProduto = SUM( Vendas[Valor] )
RETURN
    CALCULATE( VendasProduto, ALL( Produto ) )

A intenção parece ser calcular as vendas ignorando o filtro de produto. Só que VendasProduto já foi avaliada com o filtro de produto ativo, antes do CALCULATE remover esse filtro. O CALCULATE( ..., ALL( Produto ) ) não tem efeito sobre um valor que já é uma constante. O resultado mantém o filtro que você achava que tinha removido. Para funcionar, a expressão que você quer recontextualizar precisa estar dentro do CALCULATE, não guardada numa variável antes dele.

Um segundo tropeço envolve variáveis e contexto de linha em iteradores. Dentro de um SUMX, por exemplo, uma variável declarada fora do iterador não enxerga a linha corrente do iterador. Se você precisa do valor por linha, declare a variável dentro da função de iteração ou use a coluna diretamente na expressão iterada.

A terceira armadilha é conceitual: tratar VAR como reatribuição. Você não pode escrever VAR x = x + 1. A variável é imutável. Se precisa de um novo valor, crie uma nova variável. Quem vem de linguagens de programação tradicionais leva um tempo para internalizar isso.

Armadilha	Sintoma	Correção
Recontextualizar variável já avaliada	CALCULATE parece não filtrar	Colocar a expressão dentro do CALCULATE
Variável fora do iterador	Valor não varia por linha	Declarar dentro do SUMX/ADDCOLUMNS
Tratar VAR como mutável	Erro de sintaxe ao reatribuir	Criar nova variável
Nome genérico demais	Difícil de manter	Nomear pela intenção de negócio

Boas práticas de quem escreve DAX para produção#

Depois de muitos modelos entregues, algumas regras se repetem e valem a pena adotar desde o começo.

Nomeie pela intenção, não pelo cálculo. VAR VendasLiquidasBR diz mais do que VAR temp1. O nome é documentação viva. Evite espaços e acentos nos nomes de variável para não brigar com o parser em cenários mais complexos, e mantenha um padrão único no time.

Uma variável, uma responsabilidade. Se você percebe que uma variável faz duas coisas, quebre em duas. Isso facilita a depuração, porque você pode trocar temporariamente o RETURN por qualquer variável intermediária e inspecionar o valor no visual.

Não abuse do aninhamento. Variáveis podem conter tabelas, não só escalares. Uma VAR TabelaFiltrada = FILTER( ... ) reutilizada em COUNTROWS e depois em SUMX costuma ser mais limpa e mais rápida que repetir o FILTER. Mas cuidado com tabelas grandes materializadas sem necessidade, que consomem memória.

Meça, não confie na intuição. A percepção de que variável sempre acelera é falsa. Compare com o Performance Analyzer e, quando o caso for crítico, com DAX Studio. Otimização sem medição é achismo.

Padronize no time. Convenção de nomes, indentação e uso de RETURN alinhados evitam que cada pessoa escreva de um jeito. Governança de modelo é parte da governança de dados, assunto que se conecta com governança de dados e LGPD no Power BI, sobretudo quando as medidas alimentam indicadores sensíveis regidos pela Lei nº 13.709/2018.

Essas práticas ficam mais fáceis quando o modelo por trás está bem construído. Medida boa não conserta modelo ruim, e é por isso que boa parte do nosso trabalho de Power BI começa pela camada de dados antes de chegar à camada DAX.

Onde VAR se encaixa no ecossistema Microsoft#

Variáveis são um recurso da linguagem DAX, então valem em qualquer lugar onde o motor tabular roda: Power BI, modelos semânticos no Microsoft Fabric e Analysis Services. O comportamento é o mesmo, o que muda é a plataforma de execução. No Fabric, anunciado pela Microsoft em 2023, o consumo é medido em Capacity Units e os modelos podem usar o modo Direct Lake, que lê os dados diretamente do OneLake sem importação nem DirectQuery tradicional. Medidas bem escritas, com menos reavaliações, ajudam a manter o consumo de capacidade sob controle, o que tem efeito direto no custo.

Vale lembrar que a adoção ampla do Power BI no Brasil acompanha a penetração do ecossistema Microsoft nas empresas, e a Microsoft é reconhecida como Líder no Quadrante Mágico do Gartner para plataformas de Analytics e Business Intelligence. Isso significa que DAX é uma competência com longa vida útil, e investir em escrever bem compensa. Para quem está montando ou revisando a estratégia de BI, vale a leitura do nosso guia completo de Power BI para empresas no Brasil em 2026.

Sobre licenciamento, apenas para situar: Power BI Pro e Premium Per User (PPU) são licenças por usuário, enquanto capacidades Fabric usam SKUs como F2 até F2048 e o antigo Premium usava P1 até P5. Preços variam por região e contrato e devem ser confirmados sempre na fonte oficial da Microsoft. VAR não depende de licença: é gratuito escrever DAX melhor.

Perguntas frequentes#

VAR substitui as medidas separadas que eu já tenho?

Não necessariamente. Medidas nomeadas e variáveis resolvem problemas diferentes. Se um cálculo é reutilizado em várias medidas do modelo, uma medida separada faz sentido e centraliza a lógica. Se o resultado só interessa dentro de uma única medida, a variável mantém tudo local e evita poluir o modelo com medidas auxiliares. Use os dois de forma complementar.

Variável sempre deixa a medida mais rápida?

Não. Ela evita reavaliações de subexpressões repetidas, o que costuma ajudar, mas o otimizador do DAX já elimina parte dessas repetições sozinho. Em casos simples o ganho é imperceptível. Só afirme que houve melhoria depois de medir com o Performance Analyzer ou o DAX Studio, comparando antes e depois no mesmo cenário.

Posso guardar uma tabela dentro de uma variável?

Sim. Variáveis aceitam valores escalares e tabelas. Guardar o resultado de um FILTER ou SUMMARIZE numa variável e reaproveitar é uma prática comum e muitas vezes eficiente. O cuidado é não materializar tabelas enormes sem necessidade, porque isso pressiona a memória e pode anular o ganho de performance.

Por que meu CALCULATE não filtra a variável como eu esperava?

Porque a variável foi avaliada no contexto que existia no momento da declaração, e esse valor virou constante. Um CALCULATE que muda o contexto depois não afeta um número já calculado. Se você precisa recontextualizar, coloque a expressão original dentro do CALCULATE, e não numa variável declarada antes dele.

Dá para usar VAR em colunas calculadas, não só em medidas?

Sim, a sintaxe VAR ... RETURN funciona em colunas calculadas, medidas e até em consultas DAX. A diferença é o contexto de avaliação: em coluna calculada existe contexto de linha da tabela, em medida predomina o contexto de filtro. Entender essa diferença é o que evita a maioria dos resultados inesperados.

Qual o limite de variáveis numa medida?

Não há um limite prático que atrapalhe o dia a dia. O bom senso é o limite: se a medida tem quinze variáveis e ninguém consegue ler, o problema não é o número, é a organização. Quebre a lógica, avalie se parte dela deveria virar medida reutilizável e mantenha cada variável com uma responsabilidade clara.

Conclusão#

Variáveis em DAX resolvem dois problemas ao mesmo tempo: tornam a medida legível para quem vem depois e reduzem reavaliações que pesam no motor. Não são mágica, e o ganho de performance precisa ser medido, não presumido. Mas como padrão de escrita, VAR com RETURN é uma das decisões de menor custo e maior retorno que você toma num projeto de BI. Comece nomeando pela intenção, evite recontextualizar valores já congelados e meça antes de declarar vitória.

Se a sua equipe convive com medidas lentas, modelos difíceis de manter ou indicadores que ninguém confia, podemos ajudar a colocar ordem na casa. Fale com a gente e vamos olhar o seu cenário juntos.