Rebus SqlServerTransport, «MissingIndex» из SQL Server кажется неправильным или что-то не работает должным образом

Question

SQL Server сообщает, что для таблицы сообщений, используемой Rebus, а для нее SQLServerTransport нужен другой индекс, созданный для него. Я считаю, что текущая установка индекса правильная, но что-то об использовании CTE, удалении и выводе вызывает SQL Server что-то делать.

Является ли SQL Server неправильным в индексе или CTE делает что-то неожиданное здесь?

SQL Server запрашивает и индекс по линиям

CREATE INDEX IX_<NewNameHere> 
ON [MessageQueues].[dbo].[Messages] ([id]) 
INCLUDE ([recipient], [priority]) 

, где в настоящее время кластерный индекс, как

PRIMARY KEY CLUSTERED 
(
    [recipient] ASC, 
    [priority] ASC, 
    [id] ASC 
) 
WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, 
     IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, 
     ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] 

и здесь единственный запрос быть побежал против этой БД.

exec sp_executesql N'SET NOCOUNT ON 

;WITH TopCTE AS 
(
    SELECT TOP 1 
     [id], [headers], [body] 
    FROM 
     [Messages] M WITH (ROWLOCK, READPAST) 
    WHERE  
     M.[recipient] = @recipient 
     AND M.[visible] < getdate() 
     AND M.[expiration] > getdate() 
    ORDER BY   
     [priority] ASC, [id] ASC 
) 
DELETE FROM TopCTE 
OUTPUT deleted.[id] as [id], 
     deleted.[headers] as [headers], 
     deleted.[body] as [body] 
', N'@recipient nvarchar(200)', @recipient=N'Location' 

Update: Я был неправ на запросе, который вызывал разыскиваемый индекс. Ребус делает периодическое сообщение PerformExpiredMessagesCleanupCycle, который работает с этим запросом

`` ` DELETE FROM [{_tableName}] ГДЕ [ID] IN ( Выбор TOP 1 [ID] ОТ [{_tableName}] С (ROWLOCK, READPAST) гДЕ [получатель] = @recipient И [истечения] < GETDATE() )

`` `

где полезный индекс откуда.

Answer 1

Rebus для каждой очереди периодически выполняет очистку, чтобы удалить все истекшие сообщения. Это сделал это command.CommandText =$@" DELETE FROM [{_tableName}] WHERE [id] IN ( AND [expiration] < getdate() ) ";

Если запрос был как этот command.CommandText =$@" ;with TopCTE as ( SELECT TOP 1 [id] FROM [{_tableName}] WITH (ROWLOCK, READPAST) WHERE [recipient] = @recipient AND [expiration] < getdate() ) DELETE FROM TopCTE "; тогда не будет необходимости делать вторичный поиск, который вызывает ID колонку для сканирования.

Answer 2

Что вы подразумеваете под "SQL Server сообщает, что (...) нужен другой индекс"? Где вы это видите?

Я не эксперт по SQL Server .... но когда я получить фактический план запроса от выполнения запроса на таблицу с индексом, который Ребус автоматически создает, я получаю этот план:

Теперь, поскольку я не эксперт, возможно, есть много чего, что мне не хватает, когда я смотрю на эти вещи. Но я знаю, что вещь, на которую следует обратить внимание, - это «сканирование индекса», тогда как «поиск индекса» хорош, потому что это означает, что SQL Server фактически использует индекс.

---

Для того, чтобы проверить, является ли индекс предложенного SQL Server будет иметь влияние, я провел тест, где я измеряю время, затрачиваемое конечную точку, чтобы получить 10000 сообщений.

В первом раунде испытание выполняется с обычной конфигурацией - т.е.без индекс предложил SQL Server:

10000 messages received in 12,5 s - that's 801,5 msg/s 

Во втором туре, я добавить индекс предложил SQL Server:

10000 messages received in 13,6 s - that's 736,2 msg/s 

И в этом третьем раунде я добавить индекс, предложенный SQL Сервер и падение индекса, который Ребус создает сам по себе:

10000 messages received in 13,8 s - that's 722,6 msg/s 

Вот результаты суммированы в аккуратной таблице ASCII:

+---------------+-----------+----------------------+ 
| Current index | New index | Approx. receive rate | 
+---------------+-----------+----------------------+ 
|  Yes  | No  |  800 msg/s  | 
|  Yes  | Yes |  735 msg/s  | 
|  No  | Yes |  720 msg/s  | 
+---------------+-----------+----------------------+ 

Из этого - должное, не очень тщательно, но, вероятно, достаточно показательно - тест, кажется, что это не улучшает скорость приема, если индекс предложенный SQL Server используется.