1

私はMSSQL Server 2008を使用しており、テーブルから古いレコードを定期的に削除する単純な条件のSQLリクエストを持っています（テーブル内の〜3ミルのレコード）。

このリクエストは、0 行に影響する場合でもかなりの時間 (~ 10 秒) 実行されました。

このテーブルにはいくつかのインデックスがあり、実際の実行計画では、「インデックスの削除」操作がすべての実行時間を消費していることがわかります。

削除操作の影響を受ける行がない場合、SQL Server がインデックスに対して多くの作業を行うのはなぜですか?

アップデート：

リクエスト：

delete t
from Entity t
where t.Revision <= x
AND exists (
    select 1
    from Entity tt
    where tt.Id=t.Id
    and tt.Revision > t.Revision
)

実際の実行計画 XML: pastebin.com/up2E3iP1

4

3 に答える 3

2

作業はすべてハッシュ結合を行っています。他のすべてのコストは偽物です。

そこから出てくる実際の行数は です0が、もっと多く見積もっています。

予定

計画の残りの部分に示されているコストは、(誤った) 見積もりに基づいています。

このほうがパフォーマンスが良いことがわかるかもしれません。

WITH T AS
(
SELECT *,
       ROW_NUMBER() OVER (PARTITION BY Id 
                              ORDER BY Revision DESC) AS RN
FROM Entity
)
DELETE FROM T
WHERE RN > 1
AND Revision <= 12586705
于 2013-08-23T14:06:28.413 に答える
0

結合はサブクエリよりもはるかにパフォーマンスが高いことがわかりました。

これを試して

delete t
from Entity t
inner join Entity tt ON tt.Id=t.Id
where t.Revision <= x
and tt.Revision > t.Revision

また、ID とリビジョンにインデックスがあることを確認してください。

于 2013-08-23T13:45:19.390 に答える
0

レコードを削除しない場合でも、SQL は削除するレコードがないことを確認する必要があることを忘れないでください。Entity tとの間の結合にEntity ttは < が含まれているため、追加の作業が必要になります。SET STATISTICS IO ON削除を実行する前に、クエリ ウィンドウで実行してみてください。インデックスを使用しても、かなりの量の IO が行われているに違いありません。にインデックスがあると思いますId, Revisionか？そうでない場合は、追加してみてください。

于 2013-08-23T13:45:36.377 に答える