Início / dba / Perguntas / 61894
Accepted
Paul
Asked: 2014-03-28 07:06:11 +0800 CST

Exclusividade GETDATE() quando usado em INSERT

  • 772

Recentemente eu estava lendo esta postagem no blog: Link

que contém esta seção:

Escolhendo um índice agrupado

Existem algumas estratégias para escolher seus índices clusterizados; um dos mais fáceis e melhores é adicionar outra coluna de tipo de dados datetime e usar essa coluna para seu índice clusterizado. Aqui está o que você precisa fazer:

  1. Adicione a coluna como tipo de dados datetime

  2. Eu costumo chamá-lo de data

  3. Defina o valor padrão como GetDate().

  4. Torne-o não nulo.

  5. Crie seu índice clusterizado nele antes de inserir dados em você.

Minha pergunta é se isso criaria dois valores idênticos para a data? Essa resposta muda se o paralelismo estiver em uso? (Assume valor nunca especificado, sempre vem de GetDate())

Acredito que estou correto ao presumir que não importaria devido à adição do exclusivo de bastidores, certo? Mas estou interessado de qualquer maneira.

Estou perguntando de uma perspectiva do SQL2008R2, mas estaria interessado se a resposta for diferente para qualquer versão do SQL Server de 7.0 para cima.

sql-server index

1 respostas

  1. Best Answer

    GETDATE()não é garantido que seja único, não. Especialmente se for um datetime, onde os milissegundos são arredondados para cima ou para baixo e, claro, quando nem todos os dados vêm do mesmo usuário, é quase certo que haverá colisões.

    É claro que um índice clusterizado não precisa ser exclusivo, pois o SQL Server o tornará se não for (mas apenas quando necessário). Se você mesmo precisar identificar uma linha específica (em vez de apenas o unificador para uso interno do SQL Server) e não houver outras colunas de chave candidatas (isso é possível com coisas como tabelas de log de eventos), você pode adicionar um não clusterizado chave primária que é, digamos, uma coluna IDENTITY. Ou se você realmente deseja escalar na web - e se preocupa mais com o desempenho de inserção do que com o armazenamento ou qualquer uso subsequente dos dados - você pode usar uma coluna de identificador único preenchida com NEWID().

    Exemplo

    Vamos dar uma olhada em um exemplo e ver as diferenças.

    USE tempdb;
GO

-- rely on uniqifier

CREATE TABLE dbo.Test1
(
  g DATETIME
);
CREATE CLUSTERED INDEX x ON dbo.Test1(g);


-- use an IDENTITY column

CREATE TABLE dbo.Test2
(
  i INT IDENTITY(1,1) PRIMARY KEY NONCLUSTERED,
  g DATETIME
);
CREATE CLUSTERED INDEX x ON dbo.Test2(g);


-- use a GUID

CREATE TABLE dbo.Test3
(
  n UNIQUEIDENTIFIER NOT NULL DEFAULT NEWID()
    PRIMARY KEY NONCLUSTERED,
  g DATETIME
);
CREATE CLUSTERED INDEX x ON dbo.Test3(g);
GO

    Inserir velocidade

    Preenchi todas as três tabelas com cerca de 500.000 linhas, usando o seguinte script:

    SET NOCOUNT ON;
GO
SELECT SYSDATETIME();
GO
INSERT dbo.Test1(g) 
  SELECT DATEADD(SECOND, ABS([object_id])/1000, GETDATE()) 
  FROM sys.all_columns;
GO 100

SELECT SYSDATETIME();
GO
INSERT dbo.Test2(g) 
  SELECT DATEADD(SECOND, ABS([object_id])/1000, 
  GETDATE()) FROM sys.all_columns;
GO 100

SELECT SYSDATETIME();
GO
INSERT dbo.Test3(g) 
  SELECT DATEADD(SECOND, ABS([object_id])/1000, 
  GETDATE()) FROM sys.all_columns;
GO 100

SELECT SYSDATETIME();

    Resultados:

    Uniquifier:    2.26 seconds
IDENTITY:      3.89 seconds
GUID:          5.06 seconds

    Velocidade de digitalização

    SELECT SYSDATETIME();
DBCC DROPCLEANBUFFERS;
SELECT * FROM dbo.Test1;
SELECT SYSDATETIME();
DBCC DROPCLEANBUFFERS;
SELECT * FROM dbo.Test2;
SELECT SYSDATETIME();
DBCC DROPCLEANBUFFERS;
SELECT * FROM dbo.Test3;
SELECT SYSDATETIME();

    Resultados:

    Uniquifier:  3.89 seconds
IDENTITY:    4.21 seconds
GUID:        4.85 seconds

    Espaço usado

    Olhando para resultados simples de sp_spaceused:

    EXEC sp_spaceused N'dbo.Test1';
EXEC sp_spaceused N'dbo.Test2';
EXEC sp_spaceused N'dbo.Test3';

    Resultados:

                          Rows      Reserved    Data      Index size
Test1 - Uniquifier    513300    14024 KB    13880 KB       96 KB
Test2 - IDENTITY      513300    29072 KB    15792 KB    13200 KB
Test3 - GUID          513300    49936 KB    21960 KB    27928 KB

    O uniquifier ocupa menos espaço que a coluna IDENTITY (e obviamente ambos ocupam menos que o GUID), pois é necessário apenas para colisões (e provavelmente outras otimizações que desconheço, como compactação).

    Também podemos examinar as páginas de índice para o índice clusterizado na coluna datetime (index id = 1) e a chave primária não clusterizada (index id = 2):

    DBCC TRACEON(3604,-1);

-- Uniquifier
DBCC IND('tempdb', 'dbo.Test1', 1); -- 1,747 index pages
-- no second index for this table

-- IDENTITY
DBCC IND('tempdb', 'dbo.Test2', 1); -- 1,987 index pages
DBCC IND('tempdb', 'dbo.Test2', 2); -- 1,637 index pages

-- GUID
DBCC IND('tempdb', 'dbo.Test3', 1); -- 2,764 index pages
DBCC IND('tempdb', 'dbo.Test3', 2); -- 3,472 index pages

    Conteúdo da página/linha

    E, finalmente, podemos dar uma olhada em uma página específica para ver o que está armazenado em uma linha. Eu simplesmente peguei a primeira linha de cada um dos resultados DBCC IND do índice clusterizado acima (seus valores de id de página quase certamente serão diferentes):

    DBCC PAGE('tempdb',1, 153, 1);
DBCC PAGE('tempdb',1, 199, 1);
DBCC PAGE('tempdb',1, 217, 1);

    Uniquifier - preste atenção especial ao comprimento/tamanho do registro:

    Slot 0, Offset 0x60, Length 15, DumpStyle BYTE
----------------------------^^

Record Type = PRIMARY_RECORD         Record Attributes =  NULL_BITMAP     
Record Size = 15
--------------^^

Memory Dump @0x000000000F7EA060

0000000000000000:   10000c00 0333ba00 fba20000 020000††††.....3º.û¢.....  

Slot 1, Offset 0x6f, Length 23, DumpStyle BYTE
----------------------------^^

Record Type = PRIMARY_RECORD         Record Attributes =  NULL_BITMAP VARIABLE_COLUMNS
Record Size = 23              
--------------^^       
Memory Dump @0x000000000F7EA06F

0000000000000000:   30000c00 0333ba00 fba20000 02000001 †0....3º.û¢...... 
0000000000000010:   00170001 000000††††††††††††††††††††††.......

    IDENTITY parece ter 4 bytes extras no índice clusterizado:

    Slot 0, Offset 0x60, Length 19, DumpStyle BYTE
----------------------------^^

Record Type = PRIMARY_RECORD         Record Attributes =  NULL_BITMAP     
Record Size = 19
--------------^^

Memory Dump @0x0000000011DAA060

0000000000000000:   10001000 a735ba00 fba20000 03020000 †....§5º.û¢...... 
0000000000000010:   030000†††††††††††††††††††††††††††††††...              

Slot 1, Offset 0x73, Length 27, DumpStyle BYTE
----------------------------^^

Record Type = PRIMARY_RECORD         Record Attributes =  NULL_BITMAP VARIABLE_COLUMNS
Record Size = 27              
--------------^^       
Memory Dump @0x0000000011DAA073

0000000000000000:   30001000 a735ba00 fba20000 04020000 †0...§5º.û¢...... 
0000000000000010:   03000001 001b0001 000000†††††††††††††...........

    O GUID tem 16 bytes extras no índice clusterizado:

    Slot 0, Offset 0x60, Length 31, DumpStyle BYTE
----------------------------^^

Record Type = PRIMARY_RECORD         Record Attributes =  NULL_BITMAP     
Record Size = 31
--------------^^

Memory Dump @0x0000000011DAA060

0000000000000000:   10001c00 393aba00 fba20000 f3233e73 †....9:º.û¢..ó#>s 
0000000000000010:   a36e114b b1229a80 a5cb090a 030000††††£n.K±".¥Ë  ....  

Slot 1, Offset 0x7f, Length 39, DumpStyle BYTE
----------------------------^^

Record Type = PRIMARY_RECORD         Record Attributes =  NULL_BITMAP VARIABLE_COLUMNS
Record Size = 39
--------------^^                     
Memory Dump @0x0000000011DAA07F

0000000000000000:   30001c00 393aba00 fba20000 c7bb2544 †0...9:º.û¢..Ç»%D 
0000000000000010:   4ad3574f a2c2029f e4abc9d7 03000001 †JÓWO¢Â.ä«É×.... 
0000000000000020:   00270001 000000††††††††††††††††††††††.'.....

    Conclusão

    Parece-me que, de acordo com todas as contas, é melhor deixar o unificador fazer suas próprias coisas (supondo que você não espere ser capaz de diferenciar entre duas linhas com exatamente o mesmo valor de data/hora). A única vez que você pode ter problemas com isso, se qualquer valor único for duplicado 2.147.483.648 vezes, ponto em que você ultrapassará o intervalo do unificador de número inteiro.

    • 5

relate perguntas