Como as colunas longas afetam o desempenho e o uso do disco?


26

Em nosso projeto atual, acontece com muita frequência que precisamos estender as colunas com alguns caracteres. De varchar(20)para varchar(30)e assim por diante.

Na realidade, quanto isso realmente importa? Quão bom é isso otimizado? Qual é o impacto de permitir apenas 100, 200 ou até 500 caracteres para os campos normais de "entrada"? Um e-mail pode ter apenas 320 caracteres, então ok - há um bom limite lá. Mas o que ganho se definir como 200, porque não espero endereços de email mais longos do que isso.

Normalmente, nossas tabelas não terão mais de 100.000 linhas e até 20 ou 30 dessas colunas.

Agora usamos o SQL Server 2008, mas seria interessante saber como diferentes bancos de dados lidam com esses problemas.

Caso o impacto seja muito baixo - como eu esperaria, ajudaria a obter bons argumentos (com links de links?) Para convencer meu DBA de que essa paranóia de longo campo não é realmente necessária.

Caso seja, estou aqui para aprender :-)

Respostas:


12

A resposta específica à sua pergunta (pelo menos para Oracle e provavelmente para outros bancos de dados) é que o tamanho do campo não importa, apenas o tamanho dos dados. No entanto, isso não deve ser usado como um fator determinante para definir ou não o campo para o comprimento máximo permitido. Aqui estão alguns outros problemas que você deve considerar antes de maximizar o tamanho dos campos.

Formatação Qualquer ferramenta cliente que formate os dados com base no tamanho dos campos exigirá considerações especiais de formatação. O SQL * Plus do Oracle, por exemplo, exibe o tamanho máximo das colunas Varchar2, mesmo que os dados tenham apenas um caractere. Comparar…

create table f1 (a varchar2(4000), b varchar2(4000));
create table f2 (a varchar2(5), b varchar2(5));
insert into f1 values ('a','b');
insert into f2 values ('a','b');
select * from f1;
select * from f2;

Tamanho incorreto do campo de dados fornece um mecanismo adicional para capturar / impedir dados incorretos. Uma interface não deve tentar inserir 3000 caracteres em um campo de 100 caracteres, mas se esse campo estiver definido como 4000 caracteres, é possível que sim. O erro não foi detectado no estágio de entrada de dados, mas o sistema pode ter problemas ainda mais quando outro aplicativo tenta processar os dados e engasga. Como exemplo, se você decidir indexar posteriormente o campo no Oracle, excederá o comprimento máximo da chave (dependendo do tamanho e da concatenação do bloco). Vejo…

create index i1 on f1(a);

Memória Se o aplicativo cliente alocar memória usando o tamanho máximo, o aplicativo alocaria significativamente mais memória do que o necessário. Considerações especiais teriam que ser feitas para evitar isso.

Documentação O tamanho do campo fornece outro ponto de dados da documentação sobre os dados. Poderíamos chamar todas as tabelas t1, t2, t3 etc. e todos os campos f1, f2, f3 etc., mas especificando nomes significativos, melhor entendemos os dados. Por exemplo, se uma tabela de endereços de uma empresa com clientes nos EUA tiver um campo chamado State com dois caracteres, esperamos que a abreviação de dois caracteres entre nela. Por outro lado, se o campo tiver cem caracteres, podemos esperar que o nome completo do estado seja inserido no campo.


Tudo isso dito, parece prudente estar preparado para a mudança. Só porque todos os nomes de seus produtos hoje cabem em 20 caracteres não significa que eles sempre serão. Não exagere e faça 1000, mas deixe espaço para uma expansão plausível.



A documentação é boa que você adicionou aqui e que não vi em nenhum outro lugar.
jeteon

9

Aqui está um bom ponto de partida para você.

http://www.sqlskills.com/BLOGS/KIMBERLY/post/Disk-space-is-cheap.aspx

Eu posso ter entendido mal sua pergunta original. Deixe-me ver se consigo encontrar alguns outros links para referência.

Aqui está uma boa referência sobre as seleções de tipo de dados: http://sqlfool.com/2009/05/performance-considerations-of-data-types/

Mudar de varchar (20) para varchar (30) pode parecer algo pequeno, mas você precisa entender mais sobre como as estruturas de banco de dados funcionam para estar ciente dos possíveis problemas. Por exemplo, acessar varchar (30) pode levar o ponto de inflexão de suas colunas (caso todos os 30 bytes sejam usados), podendo ser armazenado em uma página (menos de 8060 bytes). Isso levará a um aumento no espaço em disco usado, uma diminuição no desempenho e até alguma sobrecarga adicional nos logs de transações.

Aqui está um link para estruturas de banco de dados: http://technet.microsoft.com/en-us/sqlserver/gg313756.aspx

Aqui está um para divisões de página e log de trx: http://sqlskills.com/BLOGS/PAUL/post/How-expensive-are-page-splits-in-terms-of-transaction-log.aspx

HTH


7

Pensei em compartilhar outro ponto interessante, encontrado na seguinte pergunta do SO:

/programming/148398/are-there-any-disadvantages-to-always-using-nvarcharmax

Resposta original de: Nick Kavadias

Um motivo para NÃO usar campos máximos ou de texto é que você não pode executar [recriações de índice online] [1], ou seja, RECONSTRUIR COM ONLINE = ON, mesmo com o SQL Server Enterprise Edition.

[1]: http://msdn.microsoft.com/en-us/library/ms188388%28SQL.90%29.aspx "reconstruções de índice online"

Eu consideraria isso uma grande desvantagem ao adicionar colunas n / varchar (max) arbitrariamente e, de acordo com o site da MS, essa restrição contra a reconstrução de índices online permanece no SQL Server 2008, 2008 R2 e Denali; portanto, não é específico para o SQL Server 2005.

Obrigado Jeff


6

Em alguns casos, a quantidade de espaço que você aloca para um campo varchar afetará a quantidade de memória alocada para classificações na memória.

Eu achei as apresentações no SQLWorkshops.com instigantes. Esta apresentação fala sobre um caso em que uma classificação de um pedido está sendo transmitida para tempdb porque não há memória suficiente sendo alocada para os campos char / varchar.

http://webcasts2.sqlworkshops.com/webcasts.asp

Este webcast também foi apresentado como um artigo no seguinte site:

http://www.mssqltips.com/tip.asp?tip=1955

Observe nesta apresentação que a coluna que está sendo classificada não é a coluna char / varchar, mas a quantidade de espaço alocado para a coluna varchar na memória faz diferença no desempenho da consulta em alguns casos.


4

SET ANSI_PADDING ON?

Você acaba com muito espaço em branco à direita ...


3

É importante apenas relacionado ao espaço em disco e comprimento dos caracteres. Obviamente, a pesquisa em tipos de dados de caracteres e índices nesse tipo de dados atuará mais lentamente que o número inteiro, mas essa é outra discussão.

O tipo de dados Varchar é um tipo de dados "variável", portanto, se você configurar um limite de varchar (500), esse será o comprimento máximo de caracteres para esse campo. O comprimento mínimo pode estar entre 0 e 500. Por outro lado, o espaço em disco reivindicado será diferente para campos de 10, 30 ou 500 caracteres.

Às vezes, eu fazia um teste para o tipo de dados varchar (800) e para valores nulos eu tinha 17 bytes usados ​​e, para cada caractere inserido, adicionava mais um byte. Por exemplo, uma sequência de 400 caracteres tinha 417 bytes usados ​​no disco.


3

Não acho que exista diferença entre tabelas criadas com colunas de varchar (20) ou varchar ((8000), desde que o comprimento máximo real seja <= 20.

Por outro lado, em alguns casos, oferecer aos usuários a possibilidade de armazenar seqüências mais longas pode incentivá-los a fazê-lo.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.