Inside the Storage Engine:anatomie van een record
Dit is voor SQL Server 2005
- recordkop
- 4 bytes lang
- twee bytes aan metadata van records (recordtype)
- twee bytes die naar voren wijzen in het record naar de NULL-bitmap
- gedeelte met vaste lengte van het record, dat de kolommen bevat waarin gegevenstypen worden opgeslagen die een vaste lengte hebben (bijv. bigint, char(10), datetime)
- NULL-bitmap
- twee bytes voor het aantal kolommen in de record
- variabel aantal bytes om één bit per kolom in de record op te slaan, ongeacht of de kolom nullable is of niet (dit is anders en eenvoudiger dan SQL Server 2000, die slechts één bit per nullable kolom had)
- dit maakt een optimalisatie mogelijk bij het lezen van kolommen die NULL zijn
- variabele lengte kolom offset array
- twee bytes voor het aantal kolommen met variabele lengte
- twee bytes per kolom met variabele lengte, wat de verschuiving naar het einde van de kolomwaardeversie-tag geeft
- dit is alleen in SQL Server 2005 en is een 14-byte structuur die een tijdstempel plus een pointer naar het versiearchief in tempdb bevat
Dus voor één char (8000)
- 4 bytes (recordkop)
- 8000 vaste lengte
- 3 null-bitmap
- 2 bytes om variabele lengte te tellen
- 14 tijdstempel
Als u echter 40 varchar(200) kolommen had
- 4 bytes (recordkop)
- 0 vaste lengte
- 6 null-bitmap
- 2 bytes om variabele lengte te tellen
- 202 x 40 =8080
- 14 tijdstempel
Totaal =8080 + 4 + 6 + 2 + 14 =8106. WTF? U krijgt een waarschuwing wanneer u deze tabel heeft gemaakt
Ik zou er niet te veel aan vasthouden:deze informatie heeft nee praktische dagelijkse waarde