Quelles sont les principales différences de performances entre les types de données varchar et nvarchar SQL Server?

Je travaille sur une base de données pour une petite application web dans mon école en utilisant SQL Server 2005.
Je vois quelques écoles de pensée sur la question de varcharvs nvarchar:

1. À utiliser varcharsauf si vous traitez un grand nombre de données internationalisées, puis utilisez nvarchar.
2. Utilisez-le nvarcharpour tout.

Je commence à voir les mérites du point de vue 2. Je sais que nvarchar occupe deux fois plus d'espace, mais ce n'est pas nécessairement énorme car cela ne va stocker des données que pour quelques centaines d'étudiants. Pour moi, il semble qu'il serait plus facile de ne pas s'en inquiéter et de simplement autoriser tout le monde à utiliser nvarchar. Ou y a-t-il quelque chose qui me manque?

Utilisez toujours nvarchar.

Vous n'aurez peut-être jamais besoin des caractères codés sur deux octets pour la plupart des applications. Cependant, si vous devez prendre en charge les langues à double octet et que vous ne disposez que d'une prise en charge à un seul octet dans votre schéma de base de données, il est très coûteux de revenir en arrière et de le modifier dans votre application.

Le coût de la migration d'une application de varchar vers nvarchar sera bien plus élevé que le peu d'espace disque supplémentaire que vous utiliserez dans la plupart des applications.

L'espace disque n'est pas le problème ... mais la mémoire et les performances le seront. Double la lecture des pages, double taille de l'index, étrange LIKE et = comportement constant, etc.

Avez-vous besoin de stocker un script chinois, etc.? Oui ou non...

Et de MS BOL " Stockage et performances des effets d'Unicode "

Modifier :

Question SO récente soulignant à quel point les mauvaises performances de nvarchar peuvent être ...

SQL Server utilise un processeur élevé lors de la recherche dans les chaînes nvarchar

Être cohérent! REJOINDRE un VARCHAR à NVARCHAR a un grand impact sur les performances.

nvarchar va avoir une surcharge importante en mémoire, stockage, jeu de travail et indexation, donc si les spécifications dictent que ce ne sera jamais vraiment nécessaire, ne vous embêtez pas.

Je n'aurais pas de règle stricte et rapide "toujours nvarchar" car cela peut être un gaspillage complet dans de nombreuses situations - en particulier ETL de ASCII / EBCDIC ou des identificateurs et des colonnes de code qui sont souvent des clés et des clés étrangères.

D'un autre côté, il y a beaucoup de cas de colonnes, où je serais sûr de poser cette question tôt et si je n'obtenais pas une réponse rapide et rapide, je ferais la colonne nvarchar.

J'hésite à ajouter une autre réponse ici car il y en a déjà pas mal, mais il faut faire quelques remarques qui n'ont pas été faites ou qui n'ont pas été faites clairement.

Premièrement: ne pas toujours utiliser NVARCHAR. C'est une attitude / approche très dangereuse et souvent coûteuse. Et il ne vaut pas mieux dire « N'utilisez jamais de curseurs» car ils sont parfois le moyen le plus efficace de résoudre un problème particulier, et la solution habituelle pour faire une WHILEboucle sera presque toujours plus lente qu'un curseur correctement fait.

La seule fois où vous devriez utiliser le terme "toujours" est lorsque vous conseillez de "toujours faire ce qui est le mieux pour la situation". Certes, cela est souvent difficile à déterminer, en particulier lorsque vous essayez d'équilibrer les gains à court terme en temps de développement (gestionnaire: "nous avons besoin de cette fonctionnalité - que vous ne connaissiez pas jusqu'à présent - il y a une semaine!") Avec une longue - les coûts de maintenance à long terme (gestionnaire qui a initialement fait pression sur l'équipe pour terminer un projet de 3 mois dans un sprint de 3 semaines: "pourquoi avons-nous ces problèmes de performance? Comment aurions-nous pu faire X qui n'a pas de flexibilité? Nous ne pouvons pas nous permettre un sprint ou deux pour résoudre ce problème. Que pouvons-nous faire en une semaine pour revenir à nos éléments prioritaires? Et nous devons certainement consacrer plus de temps à la conception afin que cela ne se reproduise pas! ").

Deuxièmement: @ gbn répond à certains points très importants à prendre en compte lors de certaines décisions de modélisation de données lorsque le chemin n'est pas clair à 100%. Mais il y a encore plus à considérer:

• taille des fichiers journaux des transactions
• temps de réplication (si vous utilisez la réplication)
• temps nécessaire à ETL (si ETLing)
• temps nécessaire pour envoyer les journaux à un système distant et les restaurer (si vous utilisez l'envoi de journaux)
• taille des sauvegardes
• durée nécessaire pour terminer la sauvegarde
• temps nécessaire pour effectuer une restauration (cela peut être important un jour ;-)
• taille nécessaire pour tempdb
• performances des déclencheurs (pour les tables insérées et supprimées qui sont stockées dans tempdb)
• performances du versionnage des lignes (si vous utilisez SNAPSHOT ISOLATION, car le magasin de versions est dans tempdb)
• possibilité d'obtenir un nouvel espace disque lorsque le directeur financier dit qu'il vient de dépenser 1 million de dollars sur un SAN l'année dernière et qu'il n'autorisera donc pas 250 000 $ supplémentaires pour du stockage supplémentaire
• durée nécessaire aux opérations INSERT et UPDATE
• durée nécessaire à la maintenance de l'index
• etc, etc, etc.

Le gaspillage d'espace a un énorme effet de cascade sur l'ensemble du système. J'ai écrit un article expliquant en détail ce sujet: le disque est bon marché! ORLY? (inscription gratuite requise; désolé, je ne contrôle pas cette politique).

Troisièmement: bien que certaines réponses se concentrent incorrectement sur l'aspect "il s'agit d'une petite application" et que certaines suggèrent correctement "d'utiliser ce qui est approprié", aucune des réponses n'a fourni de véritables orientations au PO. Un détail important mentionné dans la question c'est que c'est une page web pour leur école. Génial! Nous pouvons donc suggérer que:

• Les champs pour les noms des étudiants et / ou des professeurs doivent probablement l' être NVARCHARcar, avec le temps, il est de plus en plus probable que des noms d'autres cultures apparaîtront à ces endroits.
• Mais pour l'adresse et les noms de ville? Le but de l'application n'a pas été indiqué (cela aurait été utile) mais en supposant que les enregistrements d'adresse, le cas échéant, ne concernent qu'une région géographique particulière (c'est-à-dire une seule langue / culture), puis utilisez-la VARCHARavec la page de code appropriée (qui est déterminé à partir du classement du champ).
• Si vous stockez des codes ISO d' État et / ou de pays (pas besoin de les stocker INT/ TINYINTpuisque les codes ISO sont de longueur fixe, lisibles par l'homme et bien, standard :) utilisez CHAR(2)pour les codes à deux lettres et CHAR(3)si vous utilisez des codes à 3 lettres. Et pensez à utiliser un classement binaire tel queLatin1_General_100_BIN2 .
• Si vous stockez des codes postaux (c'est-à-dire des codes postaux), utilisez, VARCHARcar il s'agit d'une norme internationale de ne jamais utiliser de lettre en dehors de AZ. Et oui, utilisez toujours VARCHARmême si vous ne stockez que des codes postaux américains et non INT, car les codes postaux ne sont pas des nombres, ce sont des chaînes et certains d'entre eux ont un "0" en tête. Et pensez à utiliser un classement binaire tel queLatin1_General_100_BIN2 .
• Si vous stockez des adresses e-mail et / ou des URL, utilisez-les NVARCHARcar les deux peuvent désormais contenir des caractères Unicode.
• etc....

Quatrièmement: Maintenant que les NVARCHARdonnées occupent deux fois plus d'espace que nécessaire pour les données qui s'intègrent bien VARCHAR("s'intègre bien" = ne se transforme pas en "?") Et, d'une manière ou d'une autre, comme par magie, l'application s'est développée et maintenant il y a des millions d'enregistrements dans au moins un de ces champs où la plupart des lignes sont en ASCII standard mais certaines contiennent des caractères Unicode, vous devez donc les conserver NVARCHAR, tenez compte des points suivants:

1. Si vous utilisez SQL Server 2008-2016 RTM et que vous êtes sur Enterprise Edition, OU si vous utilisez SQL Server 2016 SP1 (qui a rendu la compression de données disponible dans toutes les éditions) ou une version plus récente, vous pouvez activer la compression de données . La compression des données peut (mais pas "toujours") compresser les données Unicode dans les champs NCHARet NVARCHAR. Les facteurs déterminants sont:

   1. NCHAR(1 - 4000)et NVARCHAR(1 - 4000)utiliser le schéma de compression standard pour Unicode , mais uniquement à partir de SQL Server 2008 R2, ET uniquement pour les données IN ROW, pas OVERFLOW! Cela semble être meilleur que l'algorithme de compression ROW / PAGE habituel.
   2. NVARCHAR(MAX)et XML(et je suppose aussi VARBINARY(MAX), TEXTet NTEXT) les données IN ROW (pas hors ligne dans les pages LOB ou OVERFLOW) peuvent au moins être compressées en PAGE, mais pas en ROW. Bien sûr, la compression de PAGE dépend de la taille de la valeur en ligne: j'ai testé avec VARCHAR (MAX) et j'ai vu que 6000 lignes de caractères / octets ne se comprimeraient pas, mais 4000 lignes de caractères / octets le faisaient.
   3. Toutes les données OFF ROW, LOB ou OVERLOW = Aucune compression pour vous!

2. Si vous utilisez SQL Server 2005 ou 2008-2016 RTM et non sur Enterprise Edition, vous pouvez avoir deux champs: un VARCHARet un NVARCHAR. Par exemple, supposons que vous stockiez des URL qui sont pour la plupart toutes des caractères ASCII de base (valeurs 0 - 127) et qui, par conséquent, tiennent dans VARCHAR, mais ont parfois des caractères Unicode. Votre schéma peut inclure les 3 champs suivants:

     ...
     URLa VARCHAR(2048) NULL,
     URLu NVARCHAR(2048) NULL,
     URL AS (ISNULL(CONVERT(NVARCHAR([URLa])), [URLu])),
     CONSTRAINT [CK_TableName_OneUrlMax] CHECK (
                       ([URLa] IS NOT NULL OR [URLu] IS NOT NULL)
                   AND ([URLa] IS NULL OR [URLu] IS NULL))
   );

   Dans ce modèle, vous ne sélectionnez que dans la [URL]colonne calculée. Pour l'insertion et la mise à jour, vous déterminez le champ à utiliser en voyant si la conversion modifie la valeur entrante, qui doit être de NVARCHARtype:

   INSERT INTO TableName (..., URLa, URLu)
   VALUES (...,
           IIF (CONVERT(VARCHAR(2048), @URL) = @URL, @URL, NULL),
           IIF (CONVERT(VARCHAR(2048), @URL) <> @URL, NULL, @URL)
          );

3. Vous pouvez GZIP les valeurs entrantes VARBINARY(MAX)puis décompressez à la sortie:

   • Pour SQL Server 2005-2014: vous pouvez utiliser SQLCLR. SQL # (une bibliothèque SQLCLR que j'ai écrite) est livré avec Util_GZip et Util_GUnzip dans la version gratuite
   • Pour SQL Server 2016 et plus récent: vous pouvez utiliser les fonctions intégrées COMPRESSet DECOMPRESS, qui sont également GZip.

4. Si vous utilisez SQL Server 2017 ou une version plus récente, vous pouvez envisager de faire de la table un index de colonnes en cluster.

5. Bien que ce n'est pas une option viable encore, SQL Server 2019 introduit un support natif pour UTF-8 dans VARCHAR/ CHARtypes de données. Il y a actuellement trop de bogues avec lui pour qu'il soit utilisé, mais s'ils sont corrigés, alors c'est une option pour certains scénarios. Veuillez consulter mon article, " Prise en charge native UTF-8 dans SQL Server 2019: Sauveur ou faux prophète? ", Pour une analyse détaillée de cette nouvelle fonctionnalité.

Pour votre application, nvarchar est très bien car la taille de la base de données est petite. Dire «toujours utiliser nvarchar» est une vaste simplification excessive. Si vous n'êtes pas obligé de stocker des choses comme Kanji ou d'autres personnages fous, utilisez VARCHAR, cela utilisera beaucoup moins d'espace. Mon prédécesseur dans mon travail actuel a conçu quelque chose en utilisant NVARCHAR quand il n'était pas nécessaire. Nous l'avons récemment remplacé par VARCHAR et avons économisé 15 Go sur cette table (il était très écrit). De plus, si vous avez alors un index sur cette table et que vous souhaitez inclure cette colonne ou créer un index composite, vous venez d'agrandir la taille de votre fichier d'index.

Soyez juste réfléchi dans votre décision; dans le développement SQL et les définitions de données, il semble rarement y avoir une "réponse par défaut" (à part éviter les curseurs à tout prix, bien sûr).

Étant donné que votre application est petite, il n'y a essentiellement aucune augmentation de coût appréciable pour l'utilisation de nvarchar sur varchar, et vous vous épargnez des maux de tête potentiels si vous avez besoin de stocker des données Unicode.

En général; Commencez avec le type de données le plus cher qui a le moins de contraintes. Mettez-le en production . Si les performances commencent à être un problème, découvrez ce qui est réellement stocké dans ces nvarcharcolonnes. Y a-t-il des personnages qui ne rentreraient pas varchar? Sinon, passez à varchar. N'essayez pas de pré-optimiser avant de savoir où se trouve la douleur. Je suppose que le choix entre nvarchar / varchar n'est pas ce qui va ralentir votre application dans un avenir prévisible. Il y aura d'autres parties de l'application où le réglage des performances vous donnera beaucoup plus pour les dollars .

Depuis quelques années, tous nos projets utilisent NVARCHAR pour tout, car tous ces projets sont multilingues. Les données importées de sources externes (par exemple un fichier ASCII, etc.) sont converties en Unicode avant d'être insérées dans la base de données.

Je n'ai pas encore rencontré de problèmes liés aux performances des index plus grands, etc. Les index utilisent plus de mémoire, mais la mémoire est bon marché.

Que vous utilisiez des procédures stockées ou que vous construisiez du SQL à la volée, assurez-vous que toutes les constantes de chaîne sont préfixées par N (par exemple SET @foo = N'Hello world. ';) Afin que la constante soit également Unicode. Cela évite toute conversion de type de chaîne lors de l'exécution.

YMMV.

Je peux parler d'expérience à ce sujet, méfiez-vous nvarchar. Sauf si vous en avez absolument besoin, ce type de champ de données détruit les performances sur une plus grande base de données. J'ai hérité d'une base de données qui souffrait en termes de performances et d'espace. Nous avons pu réduire de 70% la taille d'une base de données de 30 Go! Il y a eu quelques autres modifications pour améliorer les performances, mais je suis sûr que cela varchara également beaucoup aidé. Si votre base de données a le potentiel de développer des tables à plus d'un million d'enregistrements, restez à l'écart nvarcharà tout prix.

Je traite souvent cette question au travail:

• Flux FTP d'inventaire et de prix - Les descriptions d'articles et autres textes étaient dans nvarchar lorsque varchar fonctionnait bien. La conversion de ces derniers en varchar a réduit la taille du fichier presque de moitié et a vraiment aidé avec les téléchargements.

• Le scénario ci-dessus a bien fonctionné jusqu'à ce que quelqu'un mette un caractère spécial dans la description de l'article (peut-être une marque de commerce, je ne me souviens pas)

Je n'utilise toujours pas nvarchar à chaque fois via varchar. En cas de doute ou de potentiel pour les caractères spéciaux, j'utilise nvarchar. Je trouve que j'utilise varchar surtout lorsque je contrôle à 100% ce qui remplit le champ.

Pourquoi, dans toute cette discussion, n'a-t-il pas été fait mention de l'UTF-8? Être capable de stocker la plage de caractères unicode complète ne signifie pas qu'il faut toujours allouer deux octets par caractère (ou "point de code" pour utiliser le terme UNICODE). Tout ASCII est UTF-8. SQL Server vérifie-t-il pour les champs VARCHAR () que le texte est strict ASCII (c'est-à-dire le bit zéro du premier octet)? J'espère que non.

Si vous souhaitez ensuite stocker unicode et que vous souhaitez la compatibilité avec les anciennes applications ASCII uniquement, je pense que l'utilisation de VARCHAR () et UTF-8 serait la solution miracle: il n'utilise plus d'espace que nécessaire.

Pour ceux d'entre vous qui ne connaissent pas l'UTF-8, puis-je recommander un apprêt .

Il y aura des cas exceptionnels où vous voudrez restreindre délibérément le type de données pour vous assurer qu'il ne contient pas de caractères d'un certain ensemble. Par exemple, j'avais un scénario où j'avais besoin de stocker le nom de domaine dans une base de données. L'internationalisation des noms de domaine n'était pas fiable à l'époque, il était donc préférable de limiter l'entrée au niveau de la base et d'éviter tout problème potentiel.

Si vous utilisez NVARCHARsimplement parce qu'une procédure stockée système l'exige, l'occurrence la plus fréquente étant inexplicable sp_executesqlet que votre SQL dynamique est très long, vous feriez mieux de faire des manipulations de chaînes (concaténation, remplacement, etc.) du point de vue des performances, VARCHARpuis de convertir le résultat final NVARCHARet l'introduire dans le paramètre proc. Alors non, ne l'utilisez pas toujours NVARCHAR!