Dela via

Implementering av radkomprimering

Gäller för:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceSQL-databas i Microsoft Fabric

Den här artikeln sammanfattar hur Databasmotorn implementerar radkomprimering. Den här sammanfattningen innehåller grundläggande information som hjälper dig att planera det lagringsutrymme som du behöver för dina data.

Om du aktiverar komprimering ändras endast det fysiska lagringsformatet för de data som är associerade med en datatyp, men inte dess syntax eller semantik. Programändringar krävs inte när en eller flera tabeller är aktiverade för komprimering. Det nya lagringsformatet för data har följande huvudändringar:

  • Det minskar metadatakostnaderna som är associerade med posten. Dessa metadata är information om kolumner, deras längder och förskjutningar. I vissa fall kan metadatakostnaderna vara större än det gamla lagringsformatet.

  • Den använder lagringsformat med variabel längd för numeriska typer (till exempel heltal, decimaler och flyttal) och de typer som baseras på numeriska (till exempel datetime och pengar).

  • Den lagrar fasta teckensträngar med variabellängdsformat genom att inte lagra de tomma tecknen.

Anmärkning

NULL och 0 värden för alla datatyper optimeras och tar inga byte.

Hur radkomprimering påverkar lagring

I följande tabell beskrivs hur radkomprimering påverkar de befintliga typerna i SQL Server och Azure SQL Database. Tabellen innehåller inte de besparingar som kan uppnås med hjälp av sidkomprimering.

Datatyp Påverkas lagringen? Description
tinyint Nej 1 byte är det minsta lagringsutrymme som behövs.
smallint Yes Om värdet får plats i 1 byte används endast 1 byte.
int Yes Använder endast de byte som behövs. Om ett värde till exempel kan lagras i 1 byte tar lagringen bara 1 byte.
bigint Yes Använder endast de byte som behövs. Om ett värde till exempel kan lagras i 1 byte tar lagringen bara 1 byte.
decimal Yes Använder endast de byte som behövs, oavsett vilken precision som anges. Om ett värde till exempel kan lagras i 3 byte tar lagringen bara 3 byte. Lagringsutrymmet är exakt detsamma som vardecimalformatet.
numerisk Yes Använder endast de byte som behövs, oavsett vilken precision som anges. Om ett värde till exempel kan lagras i 3 byte tar lagringen bara 3 byte. Lagringsfotavtrycket är exakt samma som lagringsformatet vardecimalt .
bit Yes Metadataomkostnaderna ökar detta till 4 bitar.
småpengar Yes Använder heltalsdatarepresentationen med hjälp av ett heltal på 4 byte. Valutavärdet multipliceras med 10 000 och det resulterande heltalsvärdet lagras genom att alla siffror tas bort efter decimaltecknet. Den här typen har en lagringsoptimering som liknar den för heltalstyper.
pengar Yes Använder heltalsdatarepresentationen med hjälp av ett heltal på 8 byte. Valutavärdet multipliceras med 10 000 och det resulterande heltalsvärdet lagras genom att alla siffror tas bort efter decimaltecknet. Den här typen har ett större intervall än smallmoney. Den här typen har en lagringsoptimering som liknar den för heltalstyper.
float Yes Minst betydande byte med nollor lagras inte. float-komprimering gäller främst för icke-störande värden i mantissa.
riktiga Yes Minst betydande byte med nollor lagras inte. verklig komprimering gäller främst för icke-bråkvärden i mantissorn.
smalldatetime Nej Använder heltalsdatarepresentationen med två heltal på 2 byte och är antalet dagar sedan 1900-01-01. Det finns ingen radkomprimeringsförmån för datumdelen av smalldatetime.

Tiden är antalet minuter sedan midnatt. Tidsvärden som är strax efter 04:00 börjar använda den andra byten.

Om en smalldatetime endast används för att representera ett datum (ett vanligt fall), är 0.0 tiden. Komprimering sparar 2 byte genom att lagra tiden i det mest betydande byteformatet för radkomprimering.
datetime Yes Använder heltalsdatarepresentationen med hjälp av två heltal på 4 byte. Heltalsvärdet representerar antalet dagar med basdatumet 1900-01-01. De första 2 byteen kan representera upp till året 2079. Komprimering kan alltid spara 2 byte här fram till den punkten. Varje heltalsvärde representerar 3,33 millisekunder. Komprimering använder de första 2 byten under de första fem minuterna och behöver den fjärde byten efter 16:00. Komprimering kan därför bara spara 1 byte efter 16.00. När datetime komprimeras som alla andra heltal sparar komprimering 2 byte i datumet.
date Nej Använder en heltalsrepresentation med 3 byte. Detta representerar datumet från 0001-01-01. För moderna datum använder radkomprimering alla 3 byte. Detta ger inga besparingar.
time Nej Använder heltalsdatarepresentationen med 3–6 byte. Det finns olika precisioner som börjar med 0 till 9 som kan ta 3–6 byte. Komprimerat utrymme används på följande sätt:

Precision = 0. Byte = 3. Varje heltalsvärde representerar en sekund. Komprimering kan representera tid upp till 18:00 med 2 byte, vilket kan spara 1 byte.

Precision = 1. Byte = 3. Varje heltalsvärde representerar 1/10 sekunder. Komprimering använder den tredje byte före 02:00. Resulterar i små besparingar.

Precision = 2. Byte = 3. På samma sätt som i föregående fall är det osannolikt att det kommer att uppnå besparingar.

Precision = 3. Byte = 4. Eftersom de första 3 byteen tas vid 05.00 uppnår det här alternativet små besparingar.

Noggrannhet = 4. Byte = 4. De första 3 byteen tas under de första 27 sekunderna. Inga besparingar förväntas.

Precision = 5, Byte = 5. Den femte byte används efter 12-12.00.

Precision = 6 och 7, Byte = 5. Uppnår inga besparingar.

Precision = 8, Byte = 6. Sjätte bytet används efter 03.00.

Det finns ingen ändring i lagringen för radkomprimering. Totalt sett kan du inte förvänta dig mycket besparingar när du komprimerar tidsdatatypen.
datetime2 Yes Använder heltalsdatarepresentationen med hjälp av 6–9 byte. De första 4 byteen representerar datumet. Antalet byte som används av tiden beror på precisionen hos den angivna tiden.

Heltalsvärdet representerar antalet dagar sedan 0001-01-01 med en övre gräns på 12/31/9999. För att representera ett datum år 2005 tar komprimering 3 byte.

Det finns inga besparingar i tid eftersom det tillåter 2–4 byte för olika tidsprecisioner. För att uppnå tidsprecision på en sekund använder komprimering därför 2 byte för tid, vilket betyder att den andra byten används efter 255 sekunder.
datetimeoffset Yes Liknar datetime2, förutom att det finns 2 byte tidszon i formatet (HH:mm).

Precis som datetime2 kan komprimering spara 2 byte.

För tidszonsvärden mm kan värdet vara 0 för de flesta fall. Komprimering kan därför spara 1 byte.

Det finns inga ändringar i lagringen för radkomprimering.
tecken Yes Avslutande utfyllnadstecken tas bort. Databasmotorn infogar samma utfyllnadstecken oavsett vilken sortering som används.
varchar Nej Ingen effekt.
text Nej Ingen effekt.
nchar Ja 1 Avslutande utfyllnadstecken tas bort. Databasmotorn infogar samma utfyllnadstecken oavsett vilken sortering som används.
nvarchar Nr 1 Ingen effekt.
ntext Nej Ingen effekt.
binary Yes Avslutande nollor tas bort.
varbinary Nej Ingen effekt.
image Nej Ingen effekt.
markören Nej Ingen effekt.
Tidsstämpel / rowversion Yes Använder heltalsdatarepresentationen med hjälp av 8 byte. Det finns en tidsstämpelräknare som underhålls för varje databas och dess värde börjar från 0. Detta kan komprimeras som alla andra heltalsvärden.
sql_variant Nej Ingen effekt.
uniqueidentifier Nej Ingen effekt.
table Nej Ingen effekt.
xml Nr 2 Ingen effekt.
Användardefinierade typer Nej Detta representeras internt som varbinärt.
FILESTREAM Nej Detta representeras internt som varbinärt.

1 Unicode-komprimering stöder datatyperna nchar och nvarchar med fast längd. Datavärden som lagras utanför rad eller i nvarchar(max) -kolumner komprimeras inte. Unicode-komprimering stöds inte för nvarchar(max) data även om de lagras på rad.

2 Data utanför rad komprimeras inte när datakomprimering aktiveras. Till exempel använder en XML-post som är större än 8 060 byte utanför rad-sidor, som inte komprimeras.

Relaterat innehåll

  • Last updated on