Início / dba / Perguntas / 344086
Accepted
Dmitrij Kultasev
Asked: 2024-12-09 17:54:59 +0800 CST

Há alguma desvantagem em usar a ordenação UTF8 no SQL Server 2019?

  • 772

Temos algumas colunas na tabela que possivelmente poderiam obter alguns caracteres não ANSI e devemos armazená-los. Antes do SQL Server 2019, havia apenas uma opção - NVARCHARtipo de dados, no entanto, a partir do SQL Server 2019, é possível usar VARCHARo tipo de dados com as ordenações que terminam com %_UTF8. Entendo que, para compatibilidade total com o tamanho, precisarei dobrar o VARCHARtamanho das colunas, então, se fosse, VARCHAR(20)seria necessário VARCHAR(40)cobrir o caso se alguém inserisse um texto onde todos os 20 caracteres são não ANSI, mas há outras desvantagens dessa ordenação? Os dados nessa coluna serão ~99,9% apenas com caracteres ANSI.

sql-server

1 respostas

  1. Best Answer

    Entendo que para compatibilidade total com o tamanho, precisarei dobrar o VARCHARtamanho da coluna

    Talvez você precise fazer mais do que isso, dependendo dos caracteres que você tem ou irá armazenar. Como diz a documentação :

    Com a codificação UTF-8, os caracteres no intervalo ASCII (000000–00007F) requerem 1 byte, os pontos de código 000080–0007FF requerem 2 bytes, os pontos de código 000800–00FFFF requerem 3 bytes e os pontos de código 0010000–0010FFFF requerem 4 bytes.

    Por exemplo, SELECT DATALENGTH('🔥')retorna 4 usando uma ordenação UTF8, mas LENretorna 1.

    e (ênfase adicionada)

    É uma percepção comum, em CHAR(n) e VARCHAR(n) ou em NCHAR(n) e NVARCHAR(n), que n define o número de caracteres. Isso ocorre porque, no exemplo de uma coluna CHAR(10), 10 caracteres ASCII no intervalo de 0 a 127 podem ser armazenados usando uma ordenação como Latin1_General_100_CI_AI, porque cada caractere nesse intervalo usa apenas 1 byte.

    Entretanto, em CHAR(n) e VARCHAR(n), n define o tamanho da string em bytes (0–8.000), e em NCHAR(n) e NVARCHAR(n), n define o tamanho da string em pares de bytes (0–4.000). n nunca define o número de caracteres que podem ser armazenados .

    existem outras desvantagens dessa comparação?

    Toda mudança traz consigo um risco, que é mitigado pelos testes .

    Seu código e aplicativos podem não estar prontos para lidar com caracteres com comprimento variável de 1–4 bytes. Alguns dos seus T-SQL em particular podem fazer suposições usando DATALENGTH. Você também pode precisar revisar aquelas funções internas que não suportam totalmente Caracteres Suplementares (embora a maioria suporte agora).

    O suporte a UTF-8 é relativamente novo, então você pode encontrar bugs que não existem com collations de décadas atrás. Não me lembro de ter ouvido nenhuma história de terror em particular de improviso.

    Ter uma ordenação de colunas diferente da ordenação padrão do banco de dados (e tempdb !) também pode expor problemas de comparação de ordenação que eram mascarados pela situação uniforme anterior.

    • 4

relate perguntas