Início / dba / Perguntas / 210862
Accepted
aristotle2600
Asked: 2018-06-29 07:18:35 +0800 CST

Quais são as melhores práticas atuais em relação ao dimensionamento de varchar no SQL Server?

  • 772

Estou tentando entender a melhor maneira de decidir o tamanho das colunas varchar, tanto das perspectivas de armazenamento quanto de desempenho.

Desempenho
Da minha pesquisa, pareceque varchar(max) só deve ser usado se você realmente precisar; isto é, se a coluna deve acomodar mais de 8000 caracteres, uma razão é a falta de indexação (embora eu suspeite um pouco da indexação em campos varchar em geral. Eu sou muito novo nos princípios de banco de dados, então talvez isso seja infundado ) e compressão (mais uma preocupação de armazenamento). Na verdade, em geral as pessoas parecem recomendar apenas usar o que você precisa, ao fazer varchar(n).... oversizing é ruim, porque as consultas devem levar em conta o tamanho máximo possível. Mas também foi afirmado que o mecanismo usará metade do tamanho indicado como uma estimativa do tamanho real médio dos dados. Isso implicaria que se deve determinar, a partir dos dados, qual é o tamanho médio, dobrá-lo e usá-lo como n. Para dados com variabilidade muito baixa, mas diferente de zero, isso implica em um superdimensionamento de até 2x sobre o tamanho máximo, o que parece muito, mas talvez não seja? Insights seriam apreciados.

Armazenamento
Depois de ler sobre como funciona o armazenamento em linha vs. fora de linha, e tendo em mente que o armazenamento real é limitado aos dados reais, parece-me que a escolha de n tem pouca ou nenhuma influência no armazenamento (além certificando-se de que é grande o suficiente para conter tudo). Mesmo usando varchar(max) não deve ter nenhum impacto no armazenamento. Em vez disso, um objetivo pode ser limitar o tamanho real de cada linha de dados a ~8.000 bytes, se possível. Isso é uma leitura precisa das coisas?

Contexto
Alguns dos dados de nossos clientes flutuam um pouco, então geralmente fazemos colunas um pouco mais largas do que precisam ser, digamos 15-20% maiores, para essas colunas. Eu queria saber se havia outras considerações especiais; por exemplo, alguém com quem trabalho me disse para usar tamanhos 2^n - 1 (não encontrei evidências de que isso seja uma coisa ....)

Estou falando da criação inicial da tabela. Um cliente nos dirá que vai começar a nos enviar uma nova tabela e enviar dados de amostra (ou apenas o primeiro conjunto de dados de produção), que analisamos e criamos uma tabela do nosso lado para armazenar os dados. Queremos fazer a tabela do nosso lado para lidar com importações futuras, bem como o que está na amostra. Mas, certas linhas tendem a ficar mais longas, então as preenchemos.

A questão é quanto, e existem diretrizes técnicas?

sql-server performance

1 respostas

  1. Best Answer

    Independentemente do tipo de dados específico, você precisa ser capaz de armazenar o que o aplicativo solicitar. Você não pode especificar algo menor que o tamanho máximo do que realmente será salvo.

    Você também não precisa, nem deseja, especificar um comprimento de coluna maior que o tamanho real máximo que será armazenado por vários motivos: alocação de memória de consulta, potencialmente preenchendo o tamanho máximo de linha e não deixando espaço para adicionar colunas em o futuro, etc

    Verdadeiro, strings de comprimento variável e colunas binárias não têm a implicação de armazenamento que os tipos de dados de comprimento fixo (string / binário / numérico / data / etc) têm (embora algumas dessas implicações possam ser anuladas por meio de compactação de dados ou uso da SPARSEdefinição de coluna opção). No entanto, como você apontou, mesmo que não haja implicação direta de armazenamento, ainda há a implicação de desempenho de superestimar a memória necessária para consultas.

    Seja sensato. Use apenas o que precisar. Considerações podem ser feitas se houver uma alta probabilidade de que o comprimento da coluna precise aumentar no futuro próximo, mas lembre-se de que é mais fácil expandir o tamanho de uma coluna do que reduzir o tamanho. Sim, algum trabalho estará envolvido, mas como esse trabalho é meramente "potencial", enquanto as implicações de desempenho do superdimensionamento são "reais", geralmente é melhor definir colunas com base no que você realmente precisa, não no que você talvez - meio que acho que você pode precisar no futuro. Muitas mudanças de que se fala nunca acontecem, e muitas vezes as mudanças necessárias não podem ser previstas. Vá com o que você sabe.

    Em vez disso, um objetivo pode ser limitar o tamanho real de cada linha de dados a ~8.000 bytes, se possível.

    Eu não estou exatamente certo do que você está chegando aqui. O SQL Server o limitará fisicamente a pouco mais de 8.000 bytes. O uso de tipos LOB — VARCHAR(MAX), NVARCHAR(MAX), VARBINARY(MAX), XML, e os obsoletos TEXT, NTEXTe IMAGEtipos — permite ir além dessa limitação inicial de tamanho de página, mas isso se deve apenas ao posicionamento de um ponteiro (16 ou mais bytes, dependendo do tipo e da tamanho do valor que está sendo armazenado fora da linha ao usar os MAXtipos). O limite físico real da página de dados não foi alterado.

    Seu objetivo deve ser usar o mínimo de espaço físico para armazenar o que o aplicativo/negócio precisa armazenar sem quebrar ou truncar, de modo que o valor incompleto perca o significado ou cause problemas no downstream. Se você precisar armazenar uma coisa de 12.000 caracteres, use VARCHAR(MAX)porque é isso que é necessário. Se você estiver armazenando um número de telefone ou código postal/CEP, seria imprudente usar VARCHAR(100), e irresponsável usar VARCHAR(MAX).

    alguns de nossos dados de clientes flutuam um pouco, então geralmente fazemos colunas um pouco mais largas do que precisam ser, digamos 15-20% maiores, para essas colunas. Eu queria saber se havia outras considerações especiais;

    Todos os sistemas não têm pelo menos alguns dados que flutuam? Qualquer sistema que armazena o nome de uma pessoa se qualificaria, certo? Há uma variação bastante grande no comprimento dos nomes. E então você tem alguém como Prince mudando seu nome para um símbolo e agora você tem um problema totalmente diferente que não é o comprimento. É assim que as coisas são.

    Mas, para bancar o advogado do diabo por um momento: como pode o valor "15-20% maior do que o necessário" não ser o valor real necessário ? Digamos que há uma discussão sobre adicionar uma nova coluna e alguém sugere 50 caracteres, então outra pessoa diz: "bem, 20% a mais são 60, então vamos fazer 60 porque alguém pode ter 60". Se for verdade que um cliente pode ter 60, então 60 é, e sempre foi, o valor real necessário, e 50 estava errado o tempo todo.

    Claro, ajudaria se houvesse alguma indicação quanto à fonte dos dados porque:

    1. se você fizer "URL" 1024 e alguém precisar de 1060, ele precisará ser 1060 (da mesma forma, se você fizer URL VARCHARe receber reclamações de que está atrapalhando caracteres Unicode que agora são permitidos em nomes de domínio, então precisava ser NVARCHAR), mas
    2. se alguém quiser adicionar 1.000 caracteres a um campo de comentário com limite de 500 caracteres, ainda precisa ser 500. As pessoas podem ser menos prolixas nos comentários (um grande desafio para mim ;-), mas ProductSKUé melhor ser grande o suficiente para caber em todos dos SKUs do cliente.

    Estou falando da criação inicial da tabela. Um cliente nos dirá que vai começar a nos enviar uma nova tabela e enviar dados de amostra (ou apenas o primeiro conjunto de dados de produção), que analisamos e criamos uma tabela do nosso lado para armazenar os dados. Queremos fazer a tabela do nosso lado para lidar com importações futuras, bem como o que está na amostra. Mas, certas linhas tendem a ficar mais longas, então as preenchemos. A questão é quanto, e existem diretrizes técnicas?

    Você está fazendo muitas suposições aqui. Claro que alguns campos podem ficar maiores. Mas, novamente, eles podem não. Ou, alguns podem ficar menores. Alguns podem mudar de não-Unicode para Unicode (uma vez que percebam que o mundo está ficando menor e não se pode supor que os sobrenomes terão apenas caracteres básicos ASCII / inglês dos EUA). Ou eles podem parar de enviar um campo. Ou eles podem adicionar um ou mais campos no futuro. Qualquer combinação disso e de outras coisas. Então, por que focar apenas em VARCHARcolunas? E se eles estiverem enviando um INTvalor e em um ano ou dois atingirem o valor máximo e começarem a enviar um BIGINT? E se eles tiverem um campo "status" com valores de 0 a 5. Você vai apenas suporINTque é "acolchoado", pois permite o crescimento, mas provavelmente deveria ser TINYINT?

    A única coisa que você pode prever com segurança é que tentar prever como os dados de seus clientes serão alterados será errado com mais frequência do que correto. E estar certo é uma questão de sorte/coincidência (se não for sorte, então é só jogar na loteria ;).

    Então a orientação é:

    1. Não perca tempo e energia tentando responder a uma pergunta sem resposta.
    2. Em vez disso, concentre-se em obter o máximo de informações possível sobre os dados reais do seu cliente e siga em frente (ou seja, tomada de decisão baseada em dados ;-).

    Você já tem dados de exemplo, ótimo. Mas, por favor, não esqueça que você também tem os dados de contato do seu cliente: telefone e/ou e-mail. Contate-os! Peça a eles as especificações de dados (assim como o seu sistema, os dados atualmente em seu sistema podem ter um comprimento máximo de 35, mas seu sistema o define como VARCHAR(50), e seu sistema aceitará até esse comprimento, nesse caso você deve usar 50). E pergunte se eles têm planos de mudança de curto prazo e desses tipos de dados (tipo e/ou tamanho).

    • 22

relate perguntas