Início / user-305079

Vlad's questions

Martin Hope
Vlad
Asked: 2024-09-11 23:23:36 +0800 CST
  • 9

Então, eu gostaria de entender um conceito do MSSQL que é um pouco interessante para mim, mas não encontrei nenhuma resposta online até agora.

Tenho uma consulta que roda em uma tabela com mais de 100 mil linhas. Digamos que tenho algumas linhas que foram criadas em '2024-04-14', e não há linhas mais antigas do que isso.

A consulta procura entradas com este filtro:

CreatedAt < '2024-04-15'

A consulta funciona bem e retornará as linhas criadas em '2024-04-14'.

Mas se eu fizer isso:

CreatedAt < '2024-04-14'

A consulta será executada até retornar um tempo limite ou demorará muito para retornar um conjunto de resultados vazio, que é o resultado esperado, já que não temos linhas anteriores a '2024-04-15'.

Você pode me dizer qual conceito de SQL ou MSSQL está envolvido aqui e como posso evitar isso? O problema é que essa consulta é usada para recuperar dados para arquivamento, esses dados serão excluídos, tudo acontece em lotes. Temos um período de retenção de 150 dias, então, usando essas informações, calculamos uma data que usamos no filtro. Depois que o trabalho de arquivamento for executado algumas vezes e arquivar todos os dados encontrados, a consulta parará de encontrar dados mais antigos do que a data especificada, mas continuará a ser executada pelo resto do dia.

ATUALIZAÇÃO 1

Então voltei com mais detalhes.

A mesa:

CREATE TABLE [dbo].[Notifications](
  [Id] [bigint] IDENTITY(1,1) NOT NULL,
  [AlertId] [int] NOT NULL,
  [ChannelId] [int] NOT NULL,
  [Status] [int] NOT NULL,
  [Identifier] [nvarchar](1024) NOT NULL,
  [CreatedAt] [datetimeoffset](7) NOT NULL,
  [CanBeRetried] [bit] NULL,
  [RetryCount] [int] NOT NULL,
  ...
CONSTRAINT [PK_Notifications] PRIMARY KEY CLUSTERED 
(
   [Id] ASC
) WITH (STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, 
 OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

CREATE NONCLUSTERED INDEX [IX_Notifications_CreatedAt] ON [dbo].[Notifications]
(
   [CreatedAt] ASC
)

CREATE NONCLUSTERED INDEX [IX_Notifications_AlertId_ChannelId_CreatedAt_Include_Identifier_Status_CanBeRetried_RetryCount] ON [dbo].[Notifications]
(
   [AlertId] ASC,
   [ChannelId] ASC,
   [CreatedAt] ASC
)
INCLUDE([Identifier],[Status],[CanBeRetried],[RetryCount]) 

CREATE NONCLUSTERED INDEX [IX_Notifications_AlertId_ChannelId_Identifier] ON [dbo].[Notifications]
(
   [AlertId] ASC,
   [ChannelId] ASC,
   [Identifier] ASC
)

CREATE NONCLUSTERED INDEX [IX_Notifications_CreatedAt_Status_Include_AlertId] ON [dbo].[Notifications]
(
   [CreatedAt] ASC,
   [Status] ASC
)
INCLUDE([AlertId])

Agora, os cenários + planos de execução. Para mais contexto, estou selecionando notificações que desejo arquivar, notificações são produzidas por um Alerta e desejo excluir do processo de arquivamento notificações que são produzidas por certos Alertas.

  1. Criado em < '2024-04-14 09:00:00' E [n].[AlertId] NÃO EM ( '76', '126', '127', '128', '129')

https://www.brentozar.com/pastetheplan/?id=ByV4zrlaA

Este leva cerca de 11 minutos para processar. Não há notificações presentes além das excluídas, mais antigas do que essa data. Então isso produzirá um conjunto de resultados vazio. O otimizador escolheu uma varredura de índice clusterizado.

  1. Criado em < '2024-04-15 09:00:00' E [n].[AlertId] NÃO EM ( '76', '126', '127', '128', '129')

https://www.brentozar.com/pastetheplan/?id=SJldhHxa0

Este leva cerca de 2 segundos para processar. Há notificações presentes além das excluídas, mais antigas que essa data. O otimizador escolheu, novamente, o mesmo Clustered Index Scan.

  1. Criado em < '2023-09-13 11:00:00' E [n].[AlertId] NÃO EM ( '76', '126', '127', '128', '129')

https://www.brentozar.com/pastetheplan/?id=SJkp2Hl6R

Este leva 1 segundo. Não há nenhuma notificação, mais antiga que essa data. Este usa um Index Seek no índice IX_Notifications_CreatedAt.

Também encontrei isso em uma postagem: https://stackoverflow.com/questions/12846283/why-is-sql-server-not-using-index-for-very-similar-datetime-query

À medida que o intervalo cresce (e, portanto, o número de pesquisas necessárias), ele estima que será mais rápido apenas escanear todo o índice agrupado (de cobertura) evitando as pesquisas. Possivelmente incorretamente no seu caso. O ponto em que ele muda de um plano para o outro é conhecido como ponto de inflexão.

Essa resposta me deixaria satisfeito se o desempenho fosse ruim nos cenários 1 e 2, mas só ficou lento no cenário 1.

sql-server