Performance SQL: y a-t-il des performances frappées en utilisant NVarchar(MAX) au lieu de NVarChar (200)
je me demande s'il y a un inconvénient à définir une colonne de type nvarchar(max) au lieu de lui donner une taille maximale (plus petite).
j'ai lu quelque part que si la valeur de la colonne a plus de 4?KB les données restantes seront ajoutées à une zone" overflow", ce qui est correct.
je crée une table où la plupart du temps le texte sera de quelques lignes, mais je me demandais s'il y avait un avantage à fixer une limite inférieure et ensuite ajouter une validation pour éviter la rupture de cette limite.
est - ce qu'il y a une restriction sur la création d'index avec la colonne nvarchar(max), ou quelque chose qui paie pour avoir à ajouter la restriction sur la limite de taille?
Merci!
3 réponses
a Strictement parler, l' MAX les types seront toujours un peu plus lents que les types non-MAX, voir comparaison des Performances de type varchar(max) vs varchar(N). Mais cette différence n'est jamais visible dans la pratique, où elle devient simplement du bruit dans la performance globale entraînée par IO.
votre principale préoccupation ne devrait pas être la performance de MAX par rapport à non-MAX. Vous devriez être concernés par la question il sera possible que cette colonne devra stocker plus de 8000 octets? si la réponse est oui, même si c'est un oui très peu probable, alors la réponse est évidente: utilisez un type MAX, la douleur pour convertir cette colonne plus tard en un type MAX ne vaut pas le petit avantage de performance des types non-MAX.
D'autres préoccupations (possibilité d'indexer cette colonne, indisponibilité des opérations d'index en ligne pour les tableaux avec des colonnes MAX) ont déjà été abordées par la réponse de Denis.
BTW, les informations sur les colonnes plus de 4KB ayant restant les données dans une zone de débordement sont erronées. L'information correcte est Table des Index et de l'Organisation:
ROW_OVERFLOW_DATA Allocation Unit
Pour chaque partition utilisée par un tableau (table en tas ou en grappes), indice, ou la vue indexée, il y en a un ROW_OVERFLOW_DATA allocation unit. Cette unité de répartition contient zéro (0) pages jusqu'à une ligne de données avec variable colonnes de longueur (varchar, nvarchar, varbinaire, ou sql_variant) dans le L'unité d'attribution des données IN_ROW_DATA dépasse la limite de taille des rangées de 8 Ko. Lorsque la taille la limitation est atteinte, SQL Server déplace la colonne avec le plus grand largeur à partir de cette ligne à une page dans le ROW_OVERFLOW_DATA allocation unit. Un Pointeur de 24 octets vers ces données hors ligne est maintenu sur la page d'origine.
Donc n'est pas des colonnes de plus de 4 KO, les lignes qui ne rentrent pas dans l'espace libre sur la page, et ce n'est pas les "restants", est l'ensemble de la colonne.
un index ne peut pas être créé sur une colonne de plus de 900 octets. Colonnes qui sont des types de données Grand objet (LOB) ntext, text,varchar(max), nvarchar(max), varbinary(max), xml, ou l'image ne peut pas être spécifié comme des colonnes de clé d'un index
vous pouvez cependant utiliser included columns
tous les types de données sont autorisés à l'exception du texte, du texte et de l'image. L'index doit être créé ou reconstruit hors ligne (ONLINE = OFF) si l'une des colonnes non-clés spécifiées est varchar (max), nvarchar (max), ou varbinary (max) types de données.
choisir nvarchar (max) peut aussi affecter les optimisations du plan d'exécution qui sont adaptées automatiquement par le moteur de serveur sql.