Dentro do mecanismo de armazenamento:anatomia de um registro

Isto é para SQL Server 2005

• cabeçalho do registro
  • 4 bytes de comprimento
  • dois bytes de metadados de registro (tipo de registro)
  • dois bytes apontando para frente no registro para o bitmap NULL
• parte de comprimento fixo do registro, contendo as colunas que armazenam tipos de dados que têm comprimentos fixos (por exemplo, bigint, char(10), datetime)
• bitmap NULL
  • dois bytes para contagem de colunas no registro
  • número variável de bytes para armazenar um bit por coluna no registro, independentemente de a coluna ser anulável ou não (isso é diferente e mais simples do que o SQL Server 2000, que tinha apenas um bit por coluna anulável)
  • isso permite uma otimização ao ler colunas que são NULL
• matriz de deslocamento de coluna de comprimento variável
  • dois bytes para a contagem de colunas de comprimento variável
  • dois bytes por coluna de comprimento variável, dando o deslocamento até o final da tag de versionamento de valor da coluna
• isso está apenas no SQL Server 2005 e é uma estrutura de 14 bytes que contém um carimbo de data/hora e um ponteiro para o armazenamento de versão em tempdb

Então, para um caractere (8000)

• 4 bytes (cabeçalho do registro)
• 8.000 comprimento fixo
• 3 bitmap nulo
• 2 bytes para contar comprimento variável
• 14 carimbos de data/hora

No entanto, se você tivesse 40 colunas varchar(200)

• 4 bytes (cabeçalho do registro)
• 0 comprimento fixo
• 6 bitmaps nulos
• 2 bytes para contar comprimento variável
• 202 x 40 =8080
• 14 carimbos de data/hora

Total =8080 + 4 + 6 + 2 + 14 =8106. WTF? Você recebe um aviso ao criar esta tabela

Eu não ficaria muito preso a isso:esta informação não valor prático do dia a dia