Os perigos do uso de nvarchar(max) em SQL para desenvolvedores do Entity Framework

Entendendo o Problema: Comportamento Padrão no Entity Framework

Tim começa descrevendo um cenário comum do Entity Framework, onde um desenvolvedor C# define um modelo com campos como FirstName e LastName. Quando a tabela é criada automaticamente no SQL Server usando migrações, o esquema gerado define esses campos de string como nvarchar(max) por padrão.

Como Tim explica, isso acontece porque o Entity Framework não sabe qual o tamanho de string apropriado para atribuir, então escolhe o caminho mais seguro — atribuindo o comprimento máximo por padrão. Isso significa que cada coluna nvarchar permite até 2^31–1 caracteres, com tamanho máximo de armazenamento em gigabytes.

Essa decisão parece conveniente, mas esconde custos de desempenho perigosos.

Exemplo de configuração com duas tabelas: nvarchar(max) vs. comprimento fixo

Para destacar o problema, Tim cria duas tabelas idênticas:

• Usuários: com nvarchar(50) para nome e sobrenome.

• UsersToTheMax: com nvarchar(max) para os mesmos campos.

Aos 2:39, Tim explica como ele preencheu ambas as tabelas com 1 milhão de linhas idênticas usando o Dapper, garantindo que apenas o tipo de dados nvarchar fosse diferente.

Essa configuração permite que ele faça uma comparação consistente entre uma coluna Unicode de comprimento fixo e uma coluna de comprimento máximo variável.

Comparando consultas e planos de execução

Tim utiliza a seguinte consulta SQL em ambas as tabelas:

SELECT * FROM dbo.Users ORDER BY LastName;
SELECT * FROM dbo.UsersToTheMax ORDER BY LastName;

Às 3h34, ele habilita o plano de execução real para analisar o que o SQL Server faz internamente ao executar essas consultas.

Observação: Este teste não se refere ao tempo total de execução em todas as máquinas — Tim enfatiza a comparação de consultas no mesmo servidor com os mesmos dados, para isolar como o nvarchar(max) afeta o desempenho.

Os resultados chocantes

Os planos de execução revelam uma diferença fundamental:

• A consulta em nvarchar(50) usa apenas 2% do custo do lote.

• A consulta em nvarchar(max) usa impressionantes 98% do custo.

Como Tim explica, isso significa que a consulta máxima é 50 vezes mais custosa em termos de como o SQL Server a processa — mesmo que as entradas de dados da coluna sejam as mesmas e relativamente pequenas.

Em termos de tempo de CPU:

• A ordenação de nvarchar(50) leva 107ms.

• A ordenação de nvarchar(max) leva 339ms.

Mas a maior diferença reside numa operação de paralelismo específica:

• Duração fixa: 0,43s

• Duração máxima: 22,17s

Isso é mais de 50 vezes mais lento, mesmo com dados idênticos.

Diferenças no consumo de memória

Tim explora as concessões de memória — quanta memória o SQL Server aloca para cada consulta:

• Consulta nvarchar(50): 340 MB

• Consulta nvarchar(max): 641 MB

Só isso já é um sinal de alerta, mas ao testar colunas não armazenadas em cache, o impacto é ainda mais drástico:

• Comprimento fixo do nome: 357 MB

• Comprimento máximo do nome: 8,5 GB

Esse aumento ocorre porque o SQL Server não sabe qual o tamanho máximo que o valor nvarchar pode atingir quando definido como max, então ele reserva um bloco de memória maior para acomodar o tamanho máximo.

Por que nvarchar(max) é tão caro?

Às 9h15, Tim explica o motivo subjacente. O tipo de dados nvarchar(max):

• Suporta até 2^31–1 caracteres Unicode, consumindo até 2 GB de espaço de armazenamento.

• Requer que o SQL Server armazene o valor fora da linha caso ele não caiba, utilizando um ponteiro em vez de armazenamento direto na linha.

• Não pode ser indexado da mesma forma que colunas de comprimento fixo.

Como resultado:

• Não é possível indexar uma coluna nvarchar(max), o que significa que o SQL Server precisa classificar ou filtrar o conjunto de dados completo sem otimização.

• Isso afeta operações como ORDER BY, WHERE ou JOINs em campos nvarchar(max).

Esse comportamento leva a um uso significativo de memória, carga na CPU e lentidão — apenas por escolher o comprimento errado dos dados de caracteres.

Recomendação final de Tim

Como Tim diz para concluir:

"Em suas consultas do Entity Framework, certifique-se de especificar o tamanho de todas as strings."

Defina sempre suas propriedades de string com um número máximo de caracteres, como nvarchar(100) ou nvarchar(255), dependendo dos dados esperados. Essa pequena alteração garante:

• Espaço de armazenamento otimizado

• Suporte para indexação

• Custo de consulta reduzido

• Melhor consistência de desempenho

Ao definir um comprimento apropriado, você torna o esquema do seu banco de dados mais eficiente e evita as armadilhas das configurações padrão inadequadas.

Conclusão

O vídeo de Tim Corey traz uma lição crucial: usar nvarchar(max) como comprimento padrão para campos de string em SQL pode prejudicar o desempenho — sem que você perceba. O SQL Server alocará memória excessiva, ignorará índices e aumentará os custos de CPU, mesmo para entradas de texto Unicode normais, como nomes ou endereços.

A conclusão? Entenda o tipo de dados nvarchar e evite o uso de max, a menos que seja realmente necessário para campos que possam armazenar documentos grandes ou conteúdo de comprimento variável.

Ao especificar o tamanho da string, você não apenas economiza bytes e memória, como também torna seu código Entity Framework e SQL mais eficiente, escalável e robusto. Seguindo as orientações de Tim, você garante que seu aplicativo não seja lento por natureza.

Para quem trabalha com bancos de dados em .NET, essa é uma prática recomendada que deve fazer parte do seu conjunto de ferramentas padrão. Confira o canal do Tim para mais vídeos relacionados a SQL.