Dans Microsoft SQL Server, les données (qui incluent les index) sont stockées dans une ou plusieurs "pages" de 8k (8192 octets). Il existe différents types de pages qui peuvent être utilisées pour gérer diverses situations (par exemple, Data, LOB, Index, AllocationMap, etc.). Chaque page a un en-tête qui contient des métadonnées sur cette page et ce qu'elle contient.
La plupart des données sont stockées dans la ligne elle-même, et une ou plusieurs de ces lignes sont à leur tour stockées dans une page pour les "données en ligne". En raison de l'espace occupé par l'en-tête de ligne, la taille maximale d'une ligne (pour les données "en ligne") est de 8 060 octets.
Cependant, toutes les données ne sont pas stockées dans la ligne. Pour certains types de données, les données peuvent en fait être stockées sur une page "données LOB" alors qu'un pointeur est laissé dans les données "en ligne" :
-
Types LOB hérités / obsolètes que personne ne devrait plus utiliser (
TEXT
,NTEXT
, etIMAGE
), par défaut, stockent toujours leurs données sur des pages LOB et utilisent toujours un pointeur de 16 octets vers cette page LOB. -
Les nouveaux types LOB (
VARCHAR(MAX)
,NVARCHAR(MAX)
,VARBINARY(MAX)
, etXML
), par défaut, tentera d'ajuster les données directement dans la ligne si cela convient. Sinon, il stockera les données sur les pages LOB et utilisera un pointeur de 24 à 72 octets (selon la taille des données LOB).
C'est ainsi que vous pouvez stocker jusqu'à 78 Go + 4 octets (ne pas oublier le INT
Clé primaire;-) sur une seule ligne :la taille de ligne maximale sera comprise entre 940 octets ((39 * 24) + 4) et 2812 octets ((39 * 72) + 4). Mais encore une fois, ce n'est que la portée maximale; si les données de chacun des 39 VARCHAR(MAX)
champs est juste de 10 octets, alors toutes les données seront stockées dans la ligne et la taille de la ligne sera de 394 octets ((39 * 10) + 4).
Étant donné que vous avez tant de champs de longueur variable (qu'ils soient MAX ou non), la seule façon d'estimer la taille des futures lignes est d'avoir une bonne idée des données que vous allez stocker dans cette table. Cependant, une table avec tous, ou même la plupart des types de données MAX implique que personne n'a vraiment la moindre idée de ce qui va être stocké dans cette table.
Dans ce sens, il convient de souligner qu'il s'agit d'une table horriblement modélisée / d'une utilisation horrible des champs de type de données MAX, et qu'elle doit être refactorisée.
Pour plus de détails sur la structure des pages de données, veuillez consulter ma réponse à la question DBA.StackExchange suivante :
SOMME des DATALENGTH ne correspondant pas à la taille de la table de sys.allocation_units