Un exemple où cela peut faire une différence est qu'il peut empêcher une optimisation des performances qui évite d'ajouter des informations de version de ligne aux tables avec des déclencheurs après.
Ceci est couvert par Paul White ici
La taille réelle des données stockées est sans importance - c'est la taille potentielle qui compte.
De même, si vous utilisez des tables à mémoire optimisée depuis 2016, il est possible d'utiliser des colonnes LOB ou des combinaisons de largeurs de colonne qui pourraient potentiellement dépasser la limite d'inrow mais avec une pénalité.
Les colonnes (Max) sont toujours stockées hors ligne. Pour les autres colonnes, si la taille de la ligne de données dans la définition de table peut dépasser 8 060 octets, SQL Server place la ou les colonnes de longueur variable les plus grandes hors ligne. Encore une fois, cela ne dépend pas de la quantité de données que vous y stockez.
Cela peut avoir un effet négatif important sur la consommation de mémoire et les performances
Un autre cas où la surdéclaration des largeurs de colonne peut faire une grande différence est si la table sera un jour traitée à l'aide de SSIS. La mémoire allouée aux colonnes de longueur variable (non BLOB) est fixée pour chaque ligne d'un arbre d'exécution et correspond à la longueur maximale déclarée des colonnes, ce qui peut entraîner une utilisation inefficace des mémoires tampons (exemple). Bien que le développeur du package SSIS puisse déclarer une taille de colonne inférieure à la source, il est préférable d'effectuer cette analyse à l'avance et de l'appliquer ici.
De retour dans le moteur SQL Server lui-même, un cas similaire est que lors du calcul de l'allocation de mémoire à allouer pour SORT opérations SQL Server suppose que varchar(x) les colonnes consommeront en moyenne x/2 octets.
Si la plupart de vos varchar les colonnes sont plus pleines que cela peut conduire au sort opérations débordant vers tempdb .
Dans votre cas si votre varchar les colonnes sont déclarées comme 8000 octets mais ont en fait un contenu bien inférieur à celui pour lequel votre requête se verra allouer de la mémoire dont elle n'a pas besoin, ce qui est évidemment inefficace et peut entraîner des attentes d'allocation de mémoire.
Ceci est couvert dans la partie 2 de SQL Workshops Webcast 1 téléchargeable ici ou voir ci-dessous.
use tempdb;
CREATE TABLE T(
id INT IDENTITY(1,1) PRIMARY KEY,
number int,
name8000 VARCHAR(8000),
name500 VARCHAR(500))
INSERT INTO T
(number,name8000,name500)
SELECT number, name, name /*<--Same contents in both cols*/
FROM master..spt_values
SELECT id,name500
FROM T
ORDER BY number
SELECT id,name8000
FROM T
ORDER BY number
