Opret en tabel med komprimering i SQL Server (T-SQL)

Når du opretter en tabel i SQL Server, har du mulighed for at bruge datakomprimering.

Datakomprimering hjælper med at reducere størrelsen af ​​databasen. Det kan også hjælpe med at forbedre ydeevnen af ​​I/O-intensive arbejdsbelastninger på grund af, at dataene bliver lagret på færre sider, hvilket reducerer antallet af sider, som forespørgsler skal læse fra disken.

For at gøre dette skal du bruge DATA_COMPRESSION mulighed ved oprettelse af tabellen.

Eksempel

Her er et eksempel til at demonstrere.

CREATE TABLE Movies (
    MovieId int IDENTITY(1,1) PRIMARY KEY NOT NULL,
    MovieName nvarchar(200)
    )
WITH (DATA_COMPRESSION = ROW);

I dette tilfælde bruger jeg rækkekomprimering.

Det følgende bruger sidekomprimering.

CREATE TABLE Movies (
    MovieId int IDENTITY(1,1) PRIMARY KEY NOT NULL,
    MovieName nvarchar(200)
    )
WITH (DATA_COMPRESSION = PAGE);

Sådan fjerner du komprimering

Du kan fjerne komprimeringen ved at bruge ALTER TABLE sætning for at genopbygge tabellen, mens du bruger NONE som komprimeringstype.

ALTER TABLE MOVIES
REBUILD WITH (DATA_COMPRESSION = NONE);

Søjlelagertabeller

Hvis du bruger kolonnelagertabeller (tabeller gemt med et klynget kolonnelagerindeks), gælder ovenstående komprimeringstyper ikke. I dette tilfælde er dine komprimeringsmuligheder COLUMNSTORE og COLUMNSTORE_ARCHIVE .

Kompressionsresultater kan variere

Mængden af ​​komprimering, du får, afhænger af dataene og typen af ​​komprimering.

ROW komprimering fjerner for eksempel unødvendige bytes fra kolonneværdierne ved at gemme dem i format med variabel længde. PAGE komprimering på den anden side gemmer de gentagne værdier kun én gang pr. side og indstiller markøren fra de respektive kolonner på siden.

Nogle gange vil du måske opdage, at komprimering af et objekt ikke altid reducerer dets størrelse, og i nogle tilfælde kan det faktisk øge dens størrelse.

Dette kan ske, hvis dine kolonner bruger en datatype, der ikke har gavn af komprimering.

Rækkekomprimering reducerer også metadataoverhead, men i nogle tilfælde kan overheaden være større end det gamle lagerformat.

Hvis dine data ikke får nogen fordel af komprimering på grund af dens datatype, er det sandsynligt, at overhead vil medføre en stigning i lagerkravene snarere end et fald.

Men variationer i kompressionsstørrelse vil også afhænge af de faktiske data. For eksempel, hvis du har en char(10) kolonne, vil komprimering fjerne eventuelle efterfølgende udfyldningstegn. Hvis du har mange rækker med efterstillede udfyldningstegn, bør du få et bedre resultat, end hvis du ikke har nogen (eller få) rækker med efterstillede polstringstegn.