À l'intérieur du moteur de stockage :anatomie d'un enregistrement
C'est pour SQL Server 2005
- en-tête d'enregistrement
- 4 octets de long
- deux octets de métadonnées d'enregistrement (type d'enregistrement)
- deux octets pointant vers l'avant dans l'enregistrement vers le bitmap NULL
- partie de longueur fixe de l'enregistrement, contenant les colonnes stockant des types de données de longueurs fixes (par exemple, bigint, char(10), datetime)
- Bitmap NULL
- deux octets pour le nombre de colonnes dans l'enregistrement
- nombre variable d'octets pour stocker un bit par colonne dans l'enregistrement, que la colonne soit nullable ou non (c'est différent et plus simple que SQL Server 2000 qui n'avait qu'un bit par colonne nullable)
- cela permet une optimisation lors de la lecture de colonnes qui sont NULL
- tableau de décalage de colonne de longueur variable
- deux octets pour le nombre de colonnes de longueur variable
- deux octets par colonne de longueur variable, donnant le décalage à la fin de la balise valueversioning de la colonne
- c'est uniquement dans SQL Server 2005 et il s'agit d'une structure de 14 octets qui contient un horodatage plus un pointeur vers le magasin de versions dans tempdb
Donc, pour un char(8000)
- 4 octets (en-tête d'enregistrement)
- 8 000 longueur fixe
- 3 bitmap nuls
- 2 octets pour compter la longueur variable
- 14 horodatage
Cependant, si vous aviez 40 colonnes varchar(200)
- 4 octets (en-tête d'enregistrement)
- 0 longueur fixe
- 6 bitmap nuls
- 2 octets pour compter la longueur variable
- 202 x 40 =8080
- 14 horodatage
Total =8080 + 4 + 6 + 2 + 14 =8106. WTF ? Vous recevez un avertissement lorsque vous créez ce tableau
Je ne m'y attarderais pas trop :cette information n'a non valeur pratique au jour le jour
