SQL ServerのRebus SqlServerTransport、 "MissingIndex"が正しくない、または何かが意図したとおりに動作していない

Question

SQL Serverは、Rebusで使用されるMessagesテーブルと、SQLServerTransportで使用されるMessagesテーブルに対して、私は現在のインデックスの設定が正しいと感じていますが、CTEの使用、削除、および出力に関する何かがSQL Serverに何かをさせる原因になっています。

インデックスにSQL Serverが間違っていますか、ここで予期しないことをしているCTEはありますか？

SQL Serverは現在、クラスタ化インデックスが

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] 

のようなもので、ここでは、このDBに対して実行されている唯一のクエリでいる

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

の線に沿って要求してインデックスされます。

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' 

アップデート： 私が欲しかったインデックスを引き起こしたクエリに間違っていました。 REBUSこのクエリ

` は[{_tableName}] FROM DELETE実行周期メッセージPerformExpiredMessagesCleanupCycle [ID]（ SELECT TOP 1 [ID]の[{_tableName}] FROM（ROWLOCK、READPAST WITHを行います所望インデックスがどこから来ている） [受信者] = @recipient AND [呼気] < GETDATE（） ）

`

です。

Answer 1

Rebusは、キューごとに定期的にクリーンアップを行い、期限切れのメッセージをすべて削除します。これは、クエリは、この command.CommandText =$@" ;with TopCTE as ( SELECT TOP 1 [id] FROM [{_tableName}] WITH (ROWLOCK, READPAST) WHERE [recipient] = @recipient AND [expiration] < getdate() ) DELETE FROM TopCTE "; のようなものだった場合は、この command.CommandText =$@" DELETE FROM [{_tableName}] WHERE [id] IN ( AND [expiration] < getdate() ) ";

が、その後ID列をスキャンする原因になっている二次検索を実行する必要がありませんでした。

Answer 2

「SQL Serverは異なるインデックスを必要とする（...）を報告していますか？あなたはそれをどこで見ますか？

私はSQL Server上の専門家ではないです....が、私はREBUSが自動的に作成されるインデックスを持つテーブルでクエリを実行するから、実際のクエリプランを取得するとき、私はこの計画を取得する：

私は専門家ではないので、これらのことを見ると、私が見逃していることが多分あります。しかし、注意すべきことは「インデックススキャン」であるのに対し、「インデックスシーク」は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によって提案されたインデックスを追加しますREBUSは、それ自体で作成したインデックスサーバーおよびドロップ：ここ

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によって提案されたインデックスを使用すると受信率は向上しません。