Um exemplo em que isso pode fazer a diferença é que pode impedir uma otimização de desempenho que evita adicionar informações de versão de linha a tabelas com acionadores posteriores.
Isso é coberto pelo SQL Kiwi aqui
O tamanho real dos dados armazenados é irrelevante - é o tamanho potencial que importa.
Da mesma forma, se estiver usando tabelas com otimização de memória desde 2016, foi possível usar colunas LOB ou combinações de larguras de coluna que poderiam potencialmente exceder o limite de inrow, mas com uma penalidade.
As colunas (máximas) são sempre armazenadas fora da linha. Para outras colunas, se o tamanho da linha de dados na definição da tabela puder exceder 8.060 bytes, o SQL Server enviará as maiores colunas de comprimento variável para fora da linha. Novamente, não depende da quantidade de dados que você armazena lá.
Isso pode ter um grande efeito negativo no consumo de memória e no desempenho
Outro caso em que declarar larguras de coluna em excesso pode fazer uma grande diferença é se a tabela será processada usando o SSIS. A memória alocada para colunas de comprimento variável (não BLOB) é fixa para cada linha em uma árvore de execução e está de acordo com o comprimento máximo declarado das colunas, o que pode levar ao uso ineficiente de buffers de memória (exemplo) . Embora o desenvolvedor do pacote SSIS possa declarar um tamanho de coluna menor do que a fonte, é melhor fazer essa análise antecipadamente e aplicá-la lá.
De volta ao próprio mecanismo do SQL Server, um caso semelhante é que, ao calcular a concessão de memória a ser alocada para SORToperações, o SQL Server presume que as varchar(x)colunas irão, em média, consumir x/2bytes.
Se a maioria de suas varcharcolunas estiver mais cheia do que isso, isso pode levar ao sortextravasamento das operações tempdb.
No seu caso, se suas varcharcolunas forem declaradas como 8000bytes, mas na verdade tiverem conteúdo muito menor do que isso, sua consulta terá memória alocada que não requer, o que é obviamente ineficiente e pode levar a esperas por concessões de memória.
Isso é abordado na Parte 2 do Webcast 1 de Workshops de SQL, que pode ser baixado aqui ou veja abaixo.
use tempdb;
CREATE TABLE T(
id INT IDENTITY(1,1) PRIMARY KEY,
number int,
name8000 VARCHAR(8000),
name500 VARCHAR(500))
INSERT INTO T
(number,name8000,name500)
SELECT number, name, name /*<--Same contents in both cols*/
FROM master..spt_values
SELECT id,name500
FROM T
ORDER BY number
SELECT id,name8000
FROM T
ORDER BY number
