Hekaton com uma reviravolta:TVPs na memória – Parte 3

1. O tipo de tabela com otimização de memória que criei tinha uma contagem de buckets de 256, mas eu estava passando até 2.000 valores para comparar. Em uma postagem de blog mais recente da equipe do SQL Server, eles explicaram que superdimensionar a contagem de buckets é melhor do que subdimensioná-la – algo que eu sabia em geral, mas não percebi que também tinha efeitos significativos nas variáveis ​​da tabela:Keep lembre-se de que, para um índice de hash, o bucket_count deve ser cerca de 1-2X o número de chaves de índice exclusivas esperadas. O superdimensionamento geralmente é melhor do que o subdimensionamento:se às vezes você insere apenas 2 valores nas variáveis, mas às vezes insere até 1.000 valores, geralmente é melhor especificar BUCKET_COUNT=1000 .
   Eles não discutem explicitamente o motivo real para isso, e tenho certeza de que há muitos detalhes técnicos nos quais podemos nos aprofundar, mas a orientação prescritiva parece ser exagerada.
2. A chave primária era um índice de hash em duas colunas, enquanto o parâmetro com valor de tabela estava apenas tentando corresponder valores em uma dessas colunas. Muito simplesmente, isso significava que o índice de hash não poderia ser usado. Tony Rogerson explica isso com um pouco mais de detalhes em uma postagem recente no blog:O hash é gerado em todas as colunas contidas no índice, você também deve especificar todas as colunas no índice de hash em sua expressão de verificação de igualdade, caso contrário, o índice não pode ser usado .
   Eu não mostrei isso antes, mas observe que o plano em relação à tabela com otimização de memória com o índice de hash de duas colunas realmente faz uma varredura de tabela em vez da busca de índice que você pode esperar no índice de hash não clusterizado (já que o principal a coluna era SalesOrderID ):
   
   
   Plano de consulta envolvendo uma tabela na memória com duas colunas índice de hash
   
   Para ser mais específico, em um índice de hash, a coluna inicial não significa um monte de beans por conta própria; o hash ainda é correspondido em todas as colunas, portanto, não funciona como um índice tradicional de árvore B (com um índice tradicional, um predicado envolvendo apenas a coluna inicial ainda pode ser muito útil na eliminação de linhas).

O que fazer?

CREATE TABLE [dbo].[SODE_InMem_1MM]
(
  [SalesOrderID] [int] NOT NULL,
  [SalesOrderDetailID] [int] NOT NULL,
  [CarrierTrackingNumber] [nvarchar](25) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
  [OrderQty] [smallint] NOT NULL,
  [ProductID] [int] NOT NULL,
  [SpecialOfferID] [int] NOT NULL,
  [UnitPrice] [money] NOT NULL,
  [UnitPriceDiscount] [money] NOT NULL,
  [LineTotal] [numeric](38, 6) NOT NULL,
  [rowguid] [uniqueidentifier] NOT NULL,
  [ModifiedDate] [datetime] NOT NULL
  PRIMARY KEY NONCLUSTERED HASH 
  (
    [SalesOrderID],
    [SalesOrderDetailID]
  ) WITH (BUCKET_COUNT = 1048576),
 
  /* I added this secondary non-clustered hash index: */
 
  INDEX x NONCLUSTERED HASH
  (
    [SalesOrderID]
  ) WITH (BUCKET_COUNT = 1048576)
 
  /* I used the same bucket count to minimize testing permutations */
 
) WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_AND_DATA);

CREATE TYPE dbo.ClassicTVP AS TABLE
(
  Item INT PRIMARY KEY
);
 
CREATE TYPE dbo.InMemoryTVP AS TABLE
(
  Item INT NOT NULL PRIMARY KEY NONCLUSTERED HASH WITH (BUCKET_COUNT = 256)
) 
WITH (MEMORY_OPTIMIZED = ON);

CREATE TYPE dbo.InMemoryTVP AS TABLE
(
  Item INT NOT NULL PRIMARY KEY NONCLUSTERED HASH WITH (BUCKET_COUNT = 2048)
) 
WITH (MEMORY_OPTIMIZED = ON);

Conclusão

• Blog da equipe do SQL Server (Tag:Hekaton e Tag:OLTP na memória – os nomes de código não são divertidos?)
• Blog de Bob Beauchemin
• Blog de Klaus Aschenbrenner