cela peut réduire la taille des tables et des index (emphase ajoutée)
Réduction de la taille est seulement possible si la plupart des personnages sont essentiellement [space]
, 0 - 9
, A - Z
, a - z
et certains signes de ponctuation de base. En dehors de cet ensemble spécifique de caractères (en termes d'utilisation pratique, valeurs ASCII standard 32 - 126), vous serez au mieux égal en taille à NVARCHAR
/ UTF-16, ou dans de nombreux cas plus grand.
Je prévois de migrer les données car je pense que la lecture de moins de données entraînera de meilleures performances pour le système.
Faites attention. L'UTF-8 n'est pas un commutateur magique «tout réparer». Toutes choses étant égales par ailleurs, oui, lire moins améliore les performances. Mais ici "toutes les autres choses" ne sont pas égales. Même lorsque vous ne stockez que des caractères ASCII standard (ce qui signifie que tous les caractères font 1 octet, ce qui nécessite donc la moitié de l'espace par rapport au stockage NVARCHAR
), il existe une légère pénalité de performance pour l'utilisation de l'UTF-8. Je crois que le problème est dû au fait que l'UTF-8 est un codage de longueur variable, ce qui signifie que chaque octet doit être interprété tel qu'il est lu afin de savoir s'il s'agit d'un caractère complet ou si l'octet suivant en fait partie. Cela signifie que toutes les opérations de chaîne doivent commencer au début et se poursuivre octet par octet. D'autre part,NVARCHAR
/ UTF-16 est toujours de 2 octets (même les caractères supplémentaires sont composés de deux points de code de 2 octets), de sorte que tout peut être lu par blocs de 2 octets.
Lors de mes tests, même avec uniquement des caractères ASCII standard, le stockage des données au format UTF-8 n'a pas permis de gagner du temps, mais était nettement pire pour le temps CPU. Et c'était sans compression de données, donc au moins il y avait moins d'espace disque utilisé. Mais, lors de l'utilisation de la compression, l'espace requis pour UTF-8 n'était que de 1% à 1,5% plus petit. Donc, effectivement, aucune économie d'espace, mais un temps processeur plus long pour UTF-8.
Les choses deviennent plus compliquées lors de l'utilisation NVARCHAR(MAX)
car la compression Unicode ne fonctionne pas avec ce type de données, même si la valeur est suffisamment petite pour être stockée en ligne. Mais, si les données sont suffisamment petites, elles devraient toujours bénéficier de la compression de lignes ou de pages (auquel cas elles deviennent en fait plus rapides que UTF-8). Cependant, les données hors ligne ne peuvent utiliser aucune compression. Pourtant, faire de la table un index de colonnes en cluster réduit considérablement la taille de NVARCHAR(MAX)
(même si elle est toujours légèrement plus grande que UTF-8 lors de l'utilisation de l'index de colonnes en cluster).
Quelqu'un peut-il pointer un scénario et une raison, ne pas utiliser les types de données char avec l'encodage UTF
Absolument. En fait, je ne trouve pas vraiment de raison impérieuse de l'utiliser dans la plupart des cas. Le seul scénario qui bénéficie vraiment de l'UTF-8 est:
- Les données sont principalement ASCII standard (valeurs 0 - 127)
- Il doit être Unicode car il peut être nécessaire de stocker une plage de caractères plus large que celle disponible sur n'importe quelle page de code 8 bits (c.-à-d.
VARCHAR
)
- La plupart des données sont stockées hors ligne (donc la compression de page ne fonctionne même pas)
- Vous disposez de suffisamment de données dont vous avez besoin / souhaitez réduire la taille pour des raisons autres que les performances de requête (par exemple, réduire la taille de la sauvegarde, réduire le temps requis pour la sauvegarde / restauration, etc.)
- Vous ne pouvez pas utiliser Clustered Columnstore Index (peut-être que l'utilisation de la table aggrave les performances dans ce cas?)
Mes tests montrent que dans presque tous les cas, NVARCHAR était plus rapide, surtout quand il y avait plus de données. En fait, 21 000 lignes avec une moyenne de 5 000 caractères par ligne nécessitaient 165 Mo pour UTF-8 et 236 Mo pour NVARCHAR
non compressé. Et pourtant, il NVARCHAR
était 2x plus rapide en temps écoulé, et au moins 2x plus rapide (parfois plus) en temps CPU. Pourtant, il occupait 71 Mo de plus sur le disque.
En dehors de cela, je ne recommanderais toujours pas d'utiliser UTF-8, au moins à partir de CTP 2, en raison d'une variété de bogues que j'ai trouvés dans cette fonctionnalité.
Pour une analyse détaillée de cette nouvelle fonctionnalité, y compris une explication des différences entre UTF-16 et UTF-8, et une liste de ces bogues, veuillez consulter mon article:
Prise en charge native UTF-8 dans SQL Server 2019: Sauveur ou faux prophète?