1

メッセージ追跡ログを含むSQLDBからデータを読み取るWebアプリがあります。パフォーマンス上の理由から、DBに2日を超えるログがないことを確認したいと思います。

通常、これは単純な課題です。削除ステートメントを使用してレコードを削除するだけですか？

残念ながら、私にとってはそれほど単純ではありませんが、テーブルには数百万のレコード数が含まれており、deleteステートメントの実行には時間がかかります。これをもっと速くする方法はありますか？

私は現在これを行っています：

DECLARE @CutOffDate datetime;
SET @CutOffDate = DATEADD(d, -2, GETDATE());

WHILE @@ROWCOUNT > 0
BEGIN
    DELETE TOP (2000) E12_MessageTracking
    WHERE [TimeStamp] < @CutOffDate;

    DELETE TOP (2000) E12_MessageTracking_Recipients
    WHERE [TimeStamp] < @CutOffDate;
END

一括挿入クエリを頻繁に実行しているため、削除も頻繁に実行できるようにする必要がありますが、現在、タスクは削除ステートメントで「オーバーラン」しており、実行されるスクリプトはリアルタイムに追いつくことができません。

アップデート：

これはあなたたちが求めたバージョン情報です：

Microsoft SQL Server 2008 R2（RTM）-10.50.1810.0（X64）2012年2月3日17:19:10 Copyright（c）Windows NT 6.1（Build 7600：）（ハイパーバイザー）上のMicrosoft Corporation Standard Edition（64ビット）

インデックスの場合、テーブルにはPK / FK関係はありませんが、MessageIDと呼ばれるフィールドに「リンク」します。問題は、MessageIDが常に入力されているとは限らないため、より適切にリンクするInternalMessageIDというサブフィールドを使用していることです。私が遭遇した問題の1つは、メッセージごとにE12_MessageTrackingテーブルに複数の行があり、E12_MessageTracking_Recipientsテーブルにリンクしていることです。

これらのテーブル間に適切な関係を持たせたいのですが、既存のInternalMessageIDまたはMessageID列を使用せずにメッセージに関連するすべてのアイテムを識別する方法がないため、現時点ではできません。

インデックスの場合、次のとおりです。

E12_MessageTracking

InternalMessageID列のインデックス。タイムスタンプとイベントに含まれる列が設定されています。

E12_MessageTracking_Recipients

InternalMessageID列のインデックス、タイムスタンプと受信者に設定された含まれる列

ありがとう、クリス。

4

1 に答える 1

1

私が最初に検討することは、テーブルTimeStampに最初のインデックス付き列であるインデックスがあることを確認することです。

より詳しく：

タイムスタンプが最初の列ではなく、クエリがその前の列でフィルタリングされない場合、インデックスは使用できません（2番目の文字がわかっている図書館で本を探すことを想像してみてください）語）。

SSMSでスクリプトの実行プランを確認することで、より良いアイデアを得ることができます。のクエリに「 」と表示されE12_MessageTrackingている場合、Table Scanインデックスは使用されていません。

于 2012-06-25T09:18:16.153 に答える