När du skapar en tabell i SQL Server har du möjlighet att använda datakomprimering.
Datakomprimering hjälper till att minska storleken på databasen. Det kan också bidra till att förbättra prestanda för I/O-intensiva arbetsbelastningar på grund av att data lagras på färre sidor, vilket minskar antalet sidor som frågor behöver läsas från disken.
För att göra detta, använd DATA_COMPRESSION
alternativet när du skapar tabellen.
Exempel
Här är ett exempel att visa.
CREATE TABLE Movies (
MovieId int IDENTITY(1,1) PRIMARY KEY NOT NULL,
MovieName nvarchar(200)
)
WITH (DATA_COMPRESSION = ROW);
I det här fallet använder jag radkomprimering.
Följande använder sidkomprimering.
CREATE TABLE Movies (
MovieId int IDENTITY(1,1) PRIMARY KEY NOT NULL,
MovieName nvarchar(200)
)
WITH (DATA_COMPRESSION = PAGE);
Hur man tar bort komprimering
Du kan ta bort komprimeringen genom att använda ALTER TABLE
uttalande för att bygga om tabellen, medan du använder NONE
som komprimeringstyp.
ALTER TABLE MOVIES
REBUILD WITH (DATA_COMPRESSION = NONE);
Columnstore-tabeller
Om du använder kolumnlagertabeller (tabeller lagrade med ett klustrat kolumnlagerindex) gäller inte ovanstående komprimeringstyper. I det här fallet är dina komprimeringsalternativ COLUMNSTORE
och COLUMNSTORE_ARCHIVE
.
Kompressionsresultat kan variera
Mängden komprimering du får beror på data och typ av komprimering.
ROW
komprimering, till exempel, tar bort onödiga bytes från kolumnvärdena genom att lagra dem i format med variabel längd. PAGE
komprimering, å andra sidan, lagrar de upprepade värdena endast en gång per sida och ställer in pekaren från respektive kolumn på sidan.
Ibland kanske du upptäcker att komprimering av ett objekt inte alltid minskar dess storlek, och i vissa fall kan det faktiskt ökas dess storlek.
Detta kan hända om dina kolumner använder en datatyp som inte drar nytta av komprimering.
Radkomprimering minskar också metadataoverhead, men i vissa fall kan overheaden vara större än det gamla lagringsformatet.
Om din data inte får någon nytta av komprimering på grund av dess datatyp, är det troligt att omkostnaderna kommer att orsaka en ökning av lagringskraven snarare än en minskning.
Men variationer i komprimeringsstorlek kommer också att bero på faktiska data. Till exempel, om du har en char(10) kolumn, kommer komprimering att ta bort alla efterföljande utfyllnadstecken. Om du har många rader med efterföljande utfyllnadstecken bör du få ett bättre resultat än om du inte har några (eller få) rader med efterföljande utfyllnadstecken.