Como evitar problemas de performance causados pelo ORM

Os ORMs (Object-Relational Mappers) tornaram-se ferramentas fundamentais no desenvolvimento de aplicações modernas. Eles permitem trabalhar com bancos de dados relacionais utilizando objetos da linguagem de programação, reduzindo a necessidade de escrever SQL manualmente e facilitando a manutenção do código.

No ecossistema .NET, o Entity Framework Core é um dos exemplos mais conhecidos dessa abordagem. Com ele, é possível consultar dados, inserir registros, atualizar entidades e gerenciar relacionamentos utilizando C#.

Apesar das vantagens, o uso inadequado de um ORM pode provocar problemas de performance, como consultas SQL excessivamente complexas, carregamento desnecessário de dados, aumento do consumo de memória e um número elevado de acessos ao banco de dados.

O problema não está necessariamente no ORM, mas na maneira como ele é utilizado.

Neste artigo, vamos entender quais são as principais armadilhas de performance associadas aos ORMs e conhecer estratégias práticas para desenvolver aplicações mais rápidas, eficientes e escaláveis.

O que é um ORM e como ele funciona?

Um ORM é uma ferramenta que estabelece um mapeamento entre os objetos de uma aplicação e as tabelas de um banco de dados relacional.

Em vez de escrever uma consulta SQL diretamente, o desenvolvedor pode utilizar os recursos da linguagem de programação para expressar o que deseja recuperar.

Por exemplo, utilizando Entity Framework Core, uma consulta para buscar clientes ativos poderia ser escrita assim:

var clientes = await context.Clientes
    .Where(c => c.Ativo)
    .ToListAsync();

O Entity Framework Core traduz essa expressão LINQ para SQL, executa a consulta no banco de dados e converte os resultados em objetos C#.

Essa abstração simplifica o desenvolvimento e permite integrar as operações de persistência com o restante da aplicação.

Entretanto, é importante compreender que o código C# não é executado diretamente no banco de dados. O ORM precisa traduzir as expressões para SQL, e o resultado dessa tradução influencia o desempenho da operação.

Além disso, fatores como a quantidade de registros retornados, os índices disponíveis, os relacionamentos entre tabelas e o plano de execução da consulta continuam sendo determinantes.

Um código aparentemente simples pode gerar uma consulta cara. Por isso, conhecer o funcionamento interno do ORM é essencial para evitar gargalos.

1. Evite o problema N+1 nas consultas

O problema N+1 é uma das causas mais conhecidas de perda de performance em aplicações que utilizam ORMs.

Ele acontece quando uma consulta inicial recupera uma coleção de registros e, posteriormente, a aplicação executa uma nova consulta para cada elemento dessa coleção.

Imagine uma aplicação que precisa listar pedidos e apresentar o nome de cada cliente associado.

Uma implementação problemática pode ser semelhante a esta:

var pedidos = await context.Pedidos
    .ToListAsync();

foreach (var pedido in pedidos)
{
    Console.WriteLine(pedido.Cliente.Nome);
}

Dependendo da configuração do ORM, do comportamento de carregamento dos relacionamentos e de como as entidades foram obtidas, o acesso a pedido.Cliente pode provocar consultas adicionais.

Nesse cenário, uma consulta inicial para recuperar os pedidos pode ser seguida por diversas consultas para carregar os clientes.

Se a aplicação recuperar 500 pedidos e executar uma consulta adicional para cada cliente, poderá chegar a centenas de acessos ao banco de dados.

O impacto é ainda maior quando a aplicação está hospedada em um ambiente remoto, no qual cada ida e volta entre a aplicação e o banco de dados possui um custo de latência.

Como evitar o N+1?

Uma alternativa é utilizar o carregamento explícito de relacionamentos com Include, quando realmente for necessário recuperar as entidades relacionadas:

var pedidos = await context.Pedidos
    .Include(p => p.Cliente)
    .ToListAsync();

Outra possibilidade, frequentemente mais eficiente para telas e APIs de consulta, é selecionar diretamente os campos necessários:

var pedidos = await context.Pedidos
    .Select(p => new
    {
        p.Id,
        p.Data,
        Cliente = p.Cliente.Nome
    })
    .ToListAsync();

Na segunda abordagem, o Entity Framework Core pode traduzir a projeção em uma consulta SQL que recupera os campos necessários, incluindo o nome do cliente por meio do relacionamento.

A tradução exata depende do modelo e da consulta gerada, mas a projeção permite evitar o carregamento completo das entidades quando isso não é necessário.

A regra prática é simples: monitore a quantidade de comandos SQL executados por uma operação e verifique se o número de consultas cresce proporcionalmente à quantidade de registros retornados.

2. Utilize AsNoTracking em consultas somente de leitura

Por padrão, o Entity Framework Core mantém o controle das entidades recuperadas por meio de consultas de rastreamento.

Esse mecanismo, conhecido como change tracking, permite identificar alterações realizadas nos objetos e persistir essas mudanças posteriormente com SaveChangesAsync().

O rastreamento é importante para operações que modificam entidades, mas pode representar trabalho adicional em consultas que apenas apresentam informações ao usuário.

Considere uma API que retorna uma lista de produtos para uma página de catálogo.

var produtos = await context.Produtos
    .Where(p => p.Ativo)
    .ToListAsync();

Se os objetos forem utilizados exclusivamente para leitura, o rastreamento pode ser desnecessário.

Nesse caso, podemos utilizar AsNoTracking():

var produtos = await context.Produtos
    .AsNoTracking()
    .Where(p => p.Ativo)
    .ToListAsync();

Com essa configuração, as entidades retornadas não são rastreadas pelo contexto da mesma maneira que em uma consulta normal com tracking.

Isso pode reduzir o trabalho de gerenciamento de estado e o consumo de memória, especialmente em consultas que retornam muitas entidades.

Entretanto, o ganho depende do cenário, do volume de dados e da complexidade do modelo.

Também é importante entender uma limitação: entidades obtidas com AsNoTracking() não são automaticamente acompanhadas pelo contexto para que suas alterações sejam detectadas por SaveChangesAsync().

Se a aplicação precisar modificar e persistir essas entidades, será necessário adotar uma estratégia apropriada de atualização.

Para APIs de leitura, relatórios e consultas de catálogo, AsNoTracking() é uma opção que vale a pena avaliar.

3. Recupere somente os campos necessários

Outro erro comum é carregar entidades completas quando a aplicação precisa apenas de algumas propriedades.

Imagine uma tabela de produtos que contém dezenas de campos, incluindo descrição detalhada, informações fiscais, dados de fornecedores e configurações internas.

Uma tela que apresenta somente o nome e o preço não precisa necessariamente recuperar todas essas informações.

Considere a seguinte consulta:

var produtos = await context.Produtos
    .ToListAsync();

Ela materializa as entidades completas retornadas pela consulta.

Uma abordagem mais direcionada seria:

var produtos = await context.Produtos
    .AsNoTracking()
    .Select(p => new ProdutoResumoDto
    {
        Id = p.Id,
        Nome = p.Nome,
        Preco = p.Preco
    })
    .ToListAsync();

Nesse exemplo, ProdutoResumoDto representa um DTO utilizado para transportar os dados necessários à apresentação.

O benefício não se limita à redução do consumo de memória na aplicação.

A projeção também pode diminuir a quantidade de dados transferidos pela rede, reduzir o trabalho de materialização dos objetos e simplificar o processamento dos resultados.

Em tabelas com colunas grandes, como campos de texto extensos, essa diferença pode ser especialmente relevante.

A recomendação é projetar os resultados de acordo com a necessidade de cada operação.

Para consultas de listagem, dashboards e endpoints de leitura, DTOs específicos frequentemente oferecem mais controle do que o carregamento indiscriminado de entidades.

4. Tenha cuidado com o uso de Include

O método Include é útil quando precisamos carregar relacionamentos junto com uma entidade principal.

Entretanto, adicionar vários Include indiscriminadamente pode produzir consultas complexas e resultados muito maiores do que o necessário.

Considere uma aplicação que recupera pedidos, itens dos pedidos e informações adicionais relacionadas a cada item.

Uma consulta poderia ser escrita assim:

var pedidos = await context.Pedidos
    .Include(p => p.Cliente)
    .Include(p => p.Itens)
        .ThenInclude(i => i.Produto)
    .ToListAsync();

Essa consulta pode ser perfeitamente adequada quando a aplicação precisa de todas essas informações.

O problema aparece quando carregamos diversos relacionamentos sem avaliar o resultado SQL produzido.

O risco do crescimento dos resultados

Quando uma consulta combina várias coleções por meio de JOIN, pode ocorrer a chamada explosão cartesiana.

Imagine que um pedido possua dez itens e esteja relacionado a uma coleção de cinco registros adicionais.

Uma consulta que combina essas duas coleções pode produzir até 50 combinações de linhas para esse pedido, dependendo dos relacionamentos e da estrutura da consulta.

Com vários pedidos e coleções maiores, a quantidade de linhas retornadas pode crescer rapidamente.

Isso aumenta o volume de dados transferidos e o trabalho necessário para reconstruir as entidades na aplicação.

Como melhorar?

Primeiro, avalie se todos os relacionamentos precisam ser carregados.

Em seguida, considere projetar os dados diretamente para um DTO ou utilizar o carregamento dividido quando ele for apropriado.

No Entity Framework Core, o método AsSplitQuery() permite executar consultas separadas para determinadas coleções incluídas no carregamento:

var pedidos = await context.Pedidos
    .Include(p => p.Itens)
    .Include(p => p.Pagamentos)
    .AsSplitQuery()
    .ToListAsync();

Essa abordagem pode reduzir a duplicação de dados causada por combinações entre coleções.

Por outro lado, consultas divididas podem exigir mais viagens ao banco de dados e apresentar outras implicações, como diferenças no comportamento transacional e na consistência dos resultados entre as consultas.

Por isso, AsSplitQuery() não deve ser aplicado indiscriminadamente.

A melhor escolha depende do tamanho das coleções, da latência, do plano de execução e do formato dos dados que a aplicação precisa retornar.

5. Implemente paginação para evitar consultas gigantes

Recuperar milhares de registros de uma só vez pode aumentar significativamente o consumo de memória, o tempo de resposta e a quantidade de dados transferidos.

Esse problema aparece com frequência em telas administrativas, relatórios, APIs de pesquisa e listagens de transações.

Uma consulta como esta pode se tornar problemática quando a tabela cresce:

var transacoes = await context.Transacoes
    .OrderByDescending(t => t.Data)
    .ToListAsync();

A aplicação recupera todos os registros correspondentes à consulta, mesmo que a interface apresente apenas uma pequena parte deles.

Uma solução é implementar paginação.

Paginação com Skip e Take

Uma implementação simples pode utilizar Skip() e Take():

int pagina = 1;
int tamanhoPagina = 20;

var transacoes = await context.Transacoes
    .AsNoTracking()
    .OrderByDescending(t => t.Data)
    .ThenByDescending(t => t.Id)
    .Skip((pagina - 1) * tamanhoPagina)
    .Take(tamanhoPagina)
    .ToListAsync();

Nesse exemplo, a consulta retorna até 20 registros.

A ordenação adicional por Id ajuda a estabelecer uma ordem determinística quando várias transações possuem a mesma data.

O uso de Skip() e Take() normalmente permite que o banco de dados limite os resultados retornados, mas não garante que a consulta seja barata.

Em tabelas muito grandes, páginas com valores elevados de Skip() podem continuar exigindo trabalho significativo do banco de dados.

Quando utilizar paginação por chave?

Para navegação sequencial em grandes conjuntos de dados, a paginação por chave, também conhecida como keyset pagination ou seek pagination, pode ser uma alternativa mais eficiente.

Em vez de ignorar milhares de registros, a consulta utiliza os valores da última linha da página anterior como referência.

Por exemplo:

var transacoes = await context.Transacoes
    .AsNoTracking()
    .Where(t => t.Id < ultimoId)
    .OrderByDescending(t => t.Id)
    .Take(20)
    .ToListAsync();

Essa estratégia funciona como exemplo quando a navegação é ordenada por um identificador crescente e a aplicação deseja percorrer os registros em ordem decrescente.

Em cenários reais, o filtro precisa corresponder à ordenação utilizada, e o índice adequado deve ser avaliado.

A paginação por chave é especialmente interessante para históricos extensos, feeds e APIs que permitem navegar continuamente pelos registros.

6. Analise o SQL gerado pelo ORM

Um dos maiores erros ao investigar problemas de performance é avaliar apenas o código C#.

O ORM transforma as expressões LINQ em comandos SQL, e é esse SQL que será executado pelo banco de dados.

Por isso, quando uma consulta apresenta lentidão, é importante verificar o comando realmente produzido.

No Entity Framework Core, podemos utilizar ToQueryString() para inspecionar o SQL de uma consulta antes de executá-la.

var consulta = context.Clientes
    .Where(c => c.Ativo)
    .OrderBy(c => c.Nome);

string sql = consulta.ToQueryString();

Console.WriteLine(sql);

Esse recurso é útil durante o desenvolvimento e o diagnóstico de consultas.

Entretanto, ToQueryString() não executa a consulta e não fornece, por si só, o plano de execução ou o tempo real de processamento no banco de dados.

Para investigar o desempenho de uma operação, também é importante analisar:

• O SQL efetivamente executado.

• O tempo gasto na execução.

• A quantidade de linhas retornadas.

• O plano de execução da consulta.

• Os índices utilizados pelo banco de dados.

• O volume de dados transferidos.

• O número de comandos executados pela aplicação.

No SQL Server, por exemplo, o plano de execução pode revelar operações de leitura excessivas, varreduras de tabelas, estimativas inadequadas de cardinalidade e outras características que ajudam a explicar a lentidão.

O importante é não assumir que uma consulta é eficiente apenas porque o código LINQ parece simples.

7. Utilize índices adequados no banco de dados

Os ORMs facilitam o acesso aos dados, mas não eliminam a necessidade de compreender os fundamentos dos bancos de dados relacionais.

Uma consulta pode ser gerada corretamente pelo Entity Framework Core e ainda apresentar desempenho ruim por falta de índices adequados.

Considere uma consulta que recupera pedidos de um determinado cliente:

var pedidos = await context.Pedidos
    .Where(p => p.ClienteId == clienteId)
    .OrderByDescending(p => p.Data)
    .ToListAsync();

Se a tabela possuir milhões de registros, a eficiência dessa consulta dependerá, entre outros fatores, da estrutura dos índices, da distribuição dos dados e do plano de execução escolhido pelo banco.

Um índice apropriado envolvendo as colunas utilizadas no filtro e na ordenação pode melhorar o desempenho.

Entretanto, não existe um índice universalmente ideal.

A escolha precisa considerar as consultas mais frequentes, a seletividade das colunas, os índices já existentes e o custo adicional de manutenção durante inserções, atualizações e exclusões.

Também é importante verificar se as expressões utilizadas nos filtros permitem que o banco aproveite os índices disponíveis.

Por exemplo, aplicar determinadas funções sobre uma coluna indexada pode dificultar o uso eficiente de um índice convencional, dependendo do banco de dados e da expressão utilizada.

Portanto, ao identificar uma consulta lenta, não tente resolver tudo apenas alterando o código C#.

Investigue também a estrutura e o comportamento do banco de dados.

8. Evite materializar dados antes da hora

Outro problema recorrente é executar operações em memória que poderiam ser realizadas diretamente pelo banco de dados.

Considere o exemplo:

var clientes = context.Clientes
    .ToList()
    .Where(c => c.Ativo)
    .ToList();

A primeira chamada a ToList() materializa os registros retornados pela consulta antes que o filtro por clientes ativos seja aplicado.

Isso significa que a aplicação pode carregar muitos registros desnecessários para depois descartá-los.

Uma implementação mais adequada seria:

var clientes = await context.Clientes
    .Where(c => c.Ativo)
    .ToListAsync();

Nesse caso, o filtro pode ser traduzido para SQL e executado no banco de dados.

A diferença é importante porque os bancos de dados relacionais possuem mecanismos próprios para filtrar, ordenar e agregar grandes conjuntos de dados.

Transferir todos os registros para a aplicação e realizar o processamento em memória pode aumentar o consumo de recursos sem trazer benefícios.

Cuidado com AsEnumerable e operações locais

Métodos como AsEnumerable() e ToList() podem alterar o local onde determinadas operações são executadas.

Depois que uma consulta passa a ser processada localmente, filtros e transformações subsequentes podem deixar de ser traduzidos para SQL.

Isso não significa que esses métodos sejam incorretos. Eles são úteis quando precisamos aplicar uma lógica que não pode ser traduzida pelo provedor de consultas.

O cuidado consiste em utilizá-los conscientemente e evitar transferir volumes excessivos de dados para a memória.

Sempre que possível, mantenha no banco de dados as operações que podem ser traduzidas de maneira eficiente para SQL.

9. Considere consultas compiladas em cenários específicos

O Entity Framework Core possui suporte a consultas compiladas explicitamente, que podem reduzir parte do custo associado ao processamento repetido de determinadas consultas LINQ.

Normalmente, o Entity Framework Core mantém mecanismos de cache para consultas e seus planos de execução internos. Por isso, consultas compiladas explicitamente não são uma solução universal para problemas de performance.

Elas podem ser interessantes em aplicações que executam repetidamente consultas estáveis e frequentes, especialmente quando o custo de processamento da consulta no lado da aplicação representa uma parcela relevante do tempo total.

Um exemplo é:

private static readonly
    Func>
    BuscarProdutoPorId =
        EF.CompileAsyncQuery(
            (AppDbContext context, int id) =>
                context.Produtos
                    .AsNoTracking()
                    .FirstOrDefault(p => p.Id == id));

A consulta pode ser executada assim:

var produto = await BuscarProdutoPorId(context, produtoId);

Nesse exemplo, AppDbContext representa o contexto de dados da aplicação, e a consulta compilada recebe o contexto e o identificador do produto como parâmetros.

É importante observar que a consulta retorna um Task, pois a operação é assíncrona e pode não encontrar um produto correspondente.

Antes de adotar essa técnica, meça o desempenho da aplicação.

Se o principal gargalo estiver no banco de dados, na rede ou na quantidade de dados retornados, a compilação da consulta pode produzir um ganho pouco significativo.

A otimização deve ser guiada por evidências, não pela quantidade de recursos avançados utilizados no código.

10. Utilize operações em lote quando apropriado

Operações que processam grandes quantidades de registros também podem sofrer com o custo de executar comandos individualmente.

Imagine uma rotina que precisa atualizar o status de milhares de pedidos.

Uma implementação que carrega cada entidade, altera uma propriedade e depois salva todas as mudanças pode exigir um volume significativo de processamento e comunicação com o banco de dados.

Em cenários compatíveis, o Entity Framework Core oferece operações em lote por meio de métodos como ExecuteUpdateAsync() e ExecuteDeleteAsync().

Esses métodos estão disponíveis a partir do Entity Framework Core 7.

Por exemplo, para marcar pedidos antigos como arquivados, podemos utilizar uma operação de atualização em lote:

var quantidadeAtualizada =
    await context.Pedidos
        .Where(p => p.Data < dataLimite && !p.Arquivado)
        .ExecuteUpdateAsync(
            setters => setters
                .SetProperty(p => p.Arquivado, true));

Nesse exemplo, a condição é aplicada à consulta e a atualização é realizada diretamente pelo banco de dados, sem exigir que cada pedido seja previamente carregado como uma entidade rastreada.

O método retorna a quantidade de linhas afetadas.

Entretanto, operações em lote possuem diferenças importantes em relação ao fluxo tradicional de alteração de entidades.

Elas não atualizam automaticamente o estado de entidades que já estejam sendo rastreadas pelo contexto. Além disso, não executam o fluxo normal de detecção de alterações para cada entidade nem substituem automaticamente a lógica de negócio que a aplicação precisa aplicar.

Se houver entidades carregadas no contexto, pode ser necessário considerar o estado desses objetos para evitar inconsistências entre a memória e o banco de dados.

Também é importante verificar se existem regras, auditorias ou comportamentos da aplicação que dependam do processamento individual de cada entidade.

Utilize operações em lote quando a atualização puder ser expressa de forma segura e eficiente diretamente no banco de dados.

11. Prefira operações assíncronas em aplicações com alta concorrência

Em aplicações web, o uso de operações assíncronas para acessar o banco de dados pode melhorar a capacidade de atendimento sob carga, especialmente quando as requisições passam uma parte significativa do tempo aguardando operações de entrada e saída.

No Entity Framework Core, métodos como ToListAsync(), FirstOrDefaultAsync() e SaveChangesAsync() permitem executar operações de banco de dados de maneira assíncrona.

Por exemplo:

var clientes = await context.Clientes
    .AsNoTracking()
    .Where(c => c.Ativo)
    .ToListAsync();

Enquanto a operação aguarda o resultado do banco de dados, a aplicação pode liberar a thread para atender a outras tarefas.

Isso pode melhorar a escalabilidade de uma aplicação ASP.NET Core sob determinadas condições.

Entretanto, é importante entender que o uso de async e await não torna automaticamente uma consulta SQL mais rápida.

Se uma consulta leva cinco segundos para ser processada pelo banco de dados, o uso de operações assíncronas não garante que esse tempo cairá.

O benefício está principalmente na forma como a aplicação gerencia a espera pelas operações de entrada e saída.

Também não se deve executar várias operações simultâneas sobre a mesma instância de DbContext, pois o Entity Framework Core não oferece suporte a operações paralelas nesse mesmo contexto.

Quando houver necessidade de executar consultas independentes em paralelo, é necessário avaliar o gerenciamento dos contextos e o impacto sobre as conexões e a carga do banco de dados.

12. Monitore as consultas em produção

Muitas vezes, uma aplicação funciona perfeitamente durante o desenvolvimento e começa a apresentar lentidão quando recebe um volume maior de usuários ou dados.

Isso acontece porque ambientes de desenvolvimento geralmente possuem menos registros, menor concorrência e condições de infraestrutura diferentes das encontradas em produção.

Por esse motivo, a análise de performance não deve ficar restrita ao código-fonte.

O Entity Framework Core oferece mecanismos de logging que permitem observar os comandos executados e coletar informações úteis durante o diagnóstico.

Por exemplo, em uma aplicação ASP.NET Core, podemos configurar o logging do contexto desta maneira:

builder.Services.AddDbContext(options =>
    options
        .UseSqlServer(
            builder.Configuration
                .GetConnectionString("DefaultConnection"))
        .LogTo(
            Console.WriteLine,
            LogLevel.Information));

Esse exemplo pressupõe que o projeto utiliza o provedor do SQL Server e possui as referências necessárias.

Em ambientes de desenvolvimento, o logging pode ajudar a identificar consultas inesperadas, comandos repetidos e operações que precisam ser investigadas.

Entretanto, o nível de detalhamento deve ser configurado com cuidado em produção.

Registrar todos os comandos pode gerar um volume elevado de logs, aumentar custos de armazenamento e expor informações que não deveriam aparecer nos registros.

A opção EnableSensitiveDataLogging() também exige atenção, pois pode incluir valores de parâmetros nos logs.

Em ambientes produtivos, prefira uma estratégia de observabilidade que permita acompanhar a duração das consultas, a quantidade de comandos, os erros e a utilização de recursos sem registrar dados sensíveis desnecessariamente.

Dependendo da infraestrutura, ferramentas de monitoramento da aplicação e do banco de dados podem complementar essas informações.

O objetivo é identificar os gargalos reais e acompanhar se as otimizações produzem os resultados esperados.

13. Saiba quando o ORM não é a melhor opção

Embora os ORMs sejam excelentes para grande parte das operações de persistência de uma aplicação, existem cenários nos quais uma abordagem diferente pode ser mais adequada.

Relatórios analíticos complexos, consultas com regras específicas de otimização, operações de importação em grande volume e processamento de dados podem exigir maior controle sobre o SQL executado.

Nessas situações, utilizar SQL diretamente ou uma ferramenta de acesso a dados mais próxima do banco pode ser uma alternativa válida.

No ecossistema .NET, o Dapper é uma opção conhecida para executar consultas SQL e mapear seus resultados para objetos C#.

Isso não significa que o Dapper seja sempre mais rápido ou que o Entity Framework Core deva ser evitado em operações complexas.

A escolha depende da consulta, da forma como os dados são utilizados, da manutenção necessária e dos requisitos da aplicação.

Uma aplicação também pode combinar as duas abordagens.

Por exemplo, o Entity Framework Core pode ser utilizado para operações convencionais de persistência, enquanto consultas SQL específicas são executadas por meio de Dapper ou de outros mecanismos adequados ao cenário.

O mais importante é evitar decisões baseadas apenas em preferências pessoais ou comparações genéricas.

Antes de substituir um ORM, identifique o gargalo, avalie alternativas e compare os resultados em condições representativas do ambiente real.

Checklist: como melhorar a performance do ORM

Antes de concluir que um ORM é responsável pela lentidão de uma aplicação, vale revisar os seguintes pontos:

• Verifique se existem consultas adicionais provocadas pelo problema N+1.

• Utilize AsNoTracking() em consultas que realmente sejam somente de leitura.

• Recupere apenas as propriedades necessárias para cada operação.

• Avalie o uso de Include e o volume de dados gerado pelos relacionamentos.

• Implemente paginação nas listagens extensas.

• Considere paginação por chave em conjuntos de dados muito grandes.

• Inspecione o SQL gerado pelo ORM.

• Analise o plano de execução das consultas lentas.

• Revise os índices das tabelas envolvidas.

• Evite materializar registros antes de aplicar filtros que podem ser executados no banco.

• Considere consultas compiladas apenas quando houver evidências de benefício.

• Utilize operações em lote para atualizações compatíveis com essa estratégia.

• Adote operações assíncronas para acessos a dados em aplicações com alta concorrência.

• Monitore a duração e a frequência das consultas em produção.

• Compare alternativas com medições reproduzíveis antes de substituir o ORM.

Esse checklist pode ser utilizado durante revisões de código, investigações de incidentes e atividades de otimização de aplicações .NET.

Conclusão

Os ORMs simplificam o desenvolvimento de aplicações e ajudam a manter o código organizado, mas não eliminam a necessidade de compreender como os bancos de dados funcionam.

Problemas como N+1, carregamento excessivo de entidades, consultas sem paginação, índices inadequados e operações desnecessárias em memória podem comprometer o desempenho mesmo quando a implementação parece simples.

A boa notícia é que grande parte desses problemas pode ser evitada com algumas práticas fundamentais: recuperar somente os dados necessários, analisar o SQL gerado, utilizar corretamente o rastreamento de entidades, projetar consultas de acordo com a necessidade da aplicação e monitorar o comportamento em produção.

Também é importante reconhecer que nem toda lentidão é causada pelo ORM. A latência da rede, o plano de execução, a estrutura dos índices, a concorrência e o volume de dados podem ter um impacto muito maior no tempo de resposta.

Em aplicações .NET, o Entity Framework Core oferece recursos suficientes para atender a uma ampla variedade de cenários. Quando utilizado com conhecimento e acompanhado por boas práticas de observabilidade, ele pode proporcionar produtividade sem comprometer a eficiência.

A regra principal é otimizar com base em evidências. Antes de reescrever uma consulta ou substituir uma tecnologia, descubra onde está o gargalo, meça o impacto e escolha a solução que melhor atende às necessidades da aplicação.

E você, já enfrentou problemas de performance causados pelo uso de um ORM?

Compartilhe sua experiência nos comentários. Se você trabalha com .NET e bancos de dados, conte quais estratégias utiliza para identificar consultas lentas e melhorar o desempenho das aplicações.

Continue acompanhando o Backstage Tech para encontrar mais conteúdos sobre desenvolvimento .NET, arquitetura de software, bancos de dados e boas práticas de engenharia de software.