Когато създавате таблица в SQL Server, имате възможност да използвате компресиране на данни.
Компресирането на данни помага за намаляване на размера на базата данни. Освен това може да помогне за подобряване на производителността на I/O интензивни натоварвания поради данните, които се съхраняват на по-малко страници, като по този начин се намалява броят на страниците, които заявките трябва да прочетат от диска.
За да направите това, използвайте DATA_COMPRESSION
опция при създаване на таблицата.
Пример
Ето пример за демонстрация.
CREATE TABLE Movies (
MovieId int IDENTITY(1,1) PRIMARY KEY NOT NULL,
MovieName nvarchar(200)
)
WITH (DATA_COMPRESSION = ROW);
В този случай използвам компресия на редове.
Следното използва компресиране на страница.
CREATE TABLE Movies (
MovieId int IDENTITY(1,1) PRIMARY KEY NOT NULL,
MovieName nvarchar(200)
)
WITH (DATA_COMPRESSION = PAGE);
Как да премахнете компресията
Можете да премахнете компресията, като използвате ALTER TABLE
израз за повторно изграждане на таблицата, докато използвате NONE
като тип компресия.
ALTER TABLE MOVIES
REBUILD WITH (DATA_COMPRESSION = NONE);
Таблици с колони
Ако използвате таблици в columnstore (таблици, съхранявани с клъстериран индекс на columnstore), горните типове компресия не се прилагат. В този случай вашите опции за компресиране са COLUMNSTORE
и COLUMNSTORE_ARCHIVE
.
Резултатите от компресията могат да варират
Размерът на компресия, който получавате, ще зависи от данните и вида на компресията.
ROW
компресията, например, премахва ненужните байтове от стойностите на колоните, като ги съхранява във формат с променлива дължина. PAGE
компресията, от друга страна, съхранява повтарящите се стойности само веднъж на страница и задава показалеца от съответните колони в страницата.
Понякога може да откриете, че компресирането на обект не винаги намалява неговия размер, а в някои случаи всъщност може да увеличи неговия размер.
Това може да се случи, ако вашите колони използват тип данни, който не се възползва от компресия.
Също така, компресирането на ред намалява излишните разходи за метаданни, но в някои случаи служебните разходи може да са по-големи от стария формат за съхранение.
Ако данните ви не получават никаква полза от компресията поради своя тип данни, тогава е вероятно режийните разходи да доведат до увеличаване на изискванията за съхранение, а не до намаляване.
Но вариациите в размера на компресията също ще зависят от действителните данни. Например, ако имате char(10) колона, компресията ще премахне всички последващи знаци за допълване. Ако имате много редове със завършващи знаци за допълване, трябва да получите по-добър резултат, отколкото ако нямате (или малко) редове със завършващи знаци за допълване.