Início / dba / Perguntas / 297390
Accepted
Ian Kemp
Asked: 2021-07-31 01:51:29 +0800 CST

Existe alguma implicação de desempenho de usar varchar(max) sobre varchar(n) em cast/convert?

  • 772

Considere a seguinte expressão, que trunca ( não arredonda ) os milissegundos de um valor de data e hora:

declare @now datetime2 = sysdatetime();
select @now;
select convert(datetime2, convert(varchar(20), @now, 120));

-- Output
2021-07-30 09:38:33.5566666
2021-07-30 09:38:33.0000000

Observe o varchar(20). Eu não gosto desse valor de comprimento específico porque se eu mudar meus tipos de dados, pode haver perda de dados:

declare @now datetimeoffset = sysdatetimeoffset() at time zone 'Pacific Standard Time';
select @now;
select convert(datetimeoffset, convert(varchar(20), @now, 120));

-- Output
2021-07-30 02:39:12.7200000 -07:00
2021-07-30 02:39:12.0000000 +00:00 -- oops, we lost the time zone too!

Por isso, prefiro usar o seguinte:

declare @now datetimeoffset = sysdatetimeoffset() at time zone 'Pacific Standard Time';
select @now;
select convert(datetimeoffset, convert(varchar(max), @now, 120)); -- note MAX not N

-- Output
2021-07-30 02:41:16.4566666 -07:00
2021-07-30 02:41:16.0000000 -07:00

Minha pergunta é: existe algum tipo de implicação significativa de desempenho no uso de varchar(max)over varchar(N)- incluindo, mas não limitado a alocações de memória?

Estou ciente de que há implicações para o desempenho da consulta se usar (max)tipos de dados sobre (N)tipos de dados em predicados , mas em meus exemplos específicos não estou fazendo isso - apenas alocando os varchars e jogando-os fora depois de convertê-los de volta para o tipo de dados desejado.

sql-server performance

1 respostas

  1. Best Answer

    Antes de mais nada, respondendo sua pergunta:

    Sim, isso pode afetar o desempenho, pois o espaço precisa ser alocado para armazenar valores grandes no mecanismo de consulta.

    No seu caso, você também pode usar um tamanho adequadamente grande, como varchar(50)o que pode conter facilmente o que você precisa.

    Mas você não deveria estar fazendo nada disso em primeiro lugar.

    Ao arredondar as datas, você não deve converter para varchare voltar, pois isso tem desempenho inferior e problemas envolvendo cultura/estilo.

    Em vez disso, use técnicas de arredondamento padrão:

    declare @now datetimeoffset = sysdatetimeoffset() at time zone 'Pacific Standard Time';
declare @epoch datetimeoffset = CAST(@now AS date);
select dateadd(
    second,
    datediff(second, @epoch, @now at time zone 'utc'),
    @epoch) at time zone 'Pacific Standard Time';
    • 5

relate perguntas