Início / dba / Perguntas / 237128
Accepted
elbillaf
Asked: 2019-05-02 06:05:04 +0800 CST

Usando o tamanho da coluna muito maior do que o necessário

  • 772

Estou criando um banco de dados SQL Server com outra pessoa. Uma das tabelas é pequena (6 linhas) com dados que provavelmente permanecerão constantes. Existe uma possibilidade remota de que uma nova linha seja adicionada. A tabela fica mais ou menos assim:

CREATE TABLE someTable (
    id int primary key identity(1,1) not null,
    name varchar(128) not null unique
    );
INSERT INTO someTable values ('alice', 'bob something', 'charles can dance', 'dugan was here');

Estou olhando para o comprimento de caracteres dessa namecoluna e acho que seus valores provavelmente nunca serão maiores que, digamos, 32 caracteres, talvez nem maiores que 24. Há alguma vantagem em mudar essa coluna para, por exemplo, varchar(32)?

Além disso, há alguma vantagem em manter os tamanhos de coluna padrão em múltiplos de 4, 8, 32, etc?

sql-server database-design

2 respostas

  1. Best Answer

    O SQL Server usa comprimentos de coluna ao alocar memória para processamento de consulta. Então, sim, resumindo, você deve sempre dimensionar as colunas adequadamente para os dados.

    As alocações de memória são baseadas no número de linhas retornadas pela consulta multiplicado pela metade do comprimento declarado da coluna.

    Dito isto, neste caso em que você tem 6 linhas, você provavelmente não deseja otimizar prematuramente. A menos que você JOIN esta tabela para outra com milhões de linhas, não haverá uma grande diferença entre um varchar(24) e um varchar(32), ou mesmo um varchar(128).

    Sua segunda pergunta é sobre o alinhamento dos comprimentos das colunas em múltiplos binários. Isso não é necessário, pois o SQL Server armazena todos os dados em páginas de 8 KB, independentemente do comprimento de cada coluna.

    • 15

  2. Com 6 linhas, não, não haverá benefício observável. Essa tabela inteira caberá em uma única página, portanto, diminuir o espaço máximo potencial que você usará nessa página enquanto ainda ocupa essa página inteira não é diferente em todo o sentido prático.

    Em mesas maiores, porém, o dimensionamento correto é crucial. A razão é que as estimativas de memória serão baseadas na suposição de que cada valor será 50% preenchido. Portanto, se você tiver varchar(128), cada valor esperará ocupar 64 bytes, independentemente dos dados reais, portanto, as concessões de memória serão 64b * número de linhas. Se todos os valores tiverem 32 caracteres ou menos, torná-lo um varchar(64) ou mesmo varchar(32) é provavelmente uma escolha melhor. Se uma grande porcentagem de valores estiver próxima ou no limite, você pode até argumentar para que o char tire a volatilidade dele.

    Quanto aos benefícios de ter comprimentos de string limitados a potências de 2, não acho que no hardware de hoje alguém possa demonstrar quaisquer vantagens óbvias.

    • 14

relate perguntas