Início / dba / Perguntas / 119913
Accepted
Ruud van de Beeten
Asked: 2015-11-04 03:06:53 +0800 CST

Efeito da alteração dos tipos de dados com compactação de linha ativada

  • 772

A empresa em que trabalho possui alguns bancos de dados SQL Server com tabelas contendo +- 500.000.000 linhas. Estamos executando as edições Enterprise do SQL Server 2008R2 e 2014.

Tipos de big data

Quando olho para os tipos de dados usados ​​na tabela maior, vejo muitas colunas BIGINT. Examinando os dados nessas colunas com um script de Thomas Larock e fazendo o script dos valores MIN() e MAX() eu mesmo, concluí que os dados nessas colunas BIGINT podem ser facilmente ajustados em colunas INT ou mesmo SMALLINT/TINYINT. (Estou ciente de que algumas colunas podem precisar do intervalo de BIGINT no futuro, portanto não estou alterando cegamente todos os tipos de dados sem falar primeiro com os desenvolvedores)

Ao comparar a possível economia ao alterar os tipos de dados, parece que a tabela poderia ter a metade do tamanho atual (sem considerar índices e outras tabelas). Esses números são sem qualquer compressão de dados.

Compressão de LINHA

Na mesa grande, a compactação ROW está habilitada. Estou me perguntando qual pode ser o impacto real de 'reduzir' os tipos de dados das colunas, tendo em mente que a compactação ROW está usando apenas os bytes necessários . Por exemplo, se um valor puder ser armazenado em 1 byte, o armazenamento levará apenas 1 byte.

pergunta real

Ajudaria a reduzir os tipos de dados, de modo que a compactação ROW usasse menos recursos? Ou é salvo dizer 'porque a compactação ROW está habilitada, não há diferença entre os tipos de dados BIGINT, INT ou SMALLINT'?

sql-server datatypes

1 respostas

  1. Best Answer

    Como a documentação que você já vinculou afirma, a compactação ROW usa apenas os bytes necessários. Uma vez que a compressão ROW está em uso, os ciclos de CPU usados ​​para converter de/para int ou bigint são os mesmos: eu não me preocuparia com isso.

    BTW, se você não tem certeza se int/bigint tem um impacto no tamanho do banco de dados ou não (não tem), você pode ver por si mesmo com uma reprodução rápida e suja:

    USE tempdb;
GO

CREATE TABLE SomeTable (
    SomeColumn bigint
)
GO

ALTER TABLE [dbo].[SomeTable] REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = NONE);

INSERT INTO SomeTable 
SELECT TOP 10000000 ROW_NUMBER() OVER (ORDER BY(SELECT NULL))
FROM sys.all_columns AS A1
CROSS JOIN sys.all_columns AS A2;
GO

-- Rebuild the heap, so that pages compact nicely
ALTER TABLE dbo.SomeTable 
REBUILD 
WITH 
(
    MAXDOP = 1, 
    ONLINE = OFF,
    FILLFACTOR = 100,
    PAD_INDEX = OFF
);
GO

SELECT SUM(page_count)
FROM sys.dm_db_index_physical_stats(
        DB_ID(),
        OBJECT_ID('SomeTable'),
        DEFAULT,
        DEFAULT,
        'detailed'
    ) AS ips;


-- 21009 pages used


ALTER TABLE [dbo].[SomeTable] REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = ROW);
GO


SELECT SUM(page_count)
FROM sys.dm_db_index_physical_stats(
        DB_ID(),
        OBJECT_ID('SomeTable'),
        DEFAULT,
        DEFAULT,
        'detailed'
    ) AS ips;

-- 13587 pages used


ALTER TABLE SomeTable ALTER COLUMN SomeColumn int;

-- Rebuild the heap, so that pages compact nicely
ALTER TABLE dbo.SomeTable 
REBUILD 
WITH 
(
    MAXDOP = 1, 
    ONLINE = OFF,
    FILLFACTOR = 100,
    PAD_INDEX = OFF
);
GO


SELECT SUM(page_count)
FROM sys.dm_db_index_physical_stats(
        DB_ID(),
        OBJECT_ID('SomeTable'),
        DEFAULT,
        DEFAULT,
        'detailed'
    ) AS ips;

-- 13587 pages used (same as bigint)
    • 4

relate perguntas