1

t-sql の通常のテーブルでの削除のパフォーマンス調整を見てきました。

しかし、テーブル変数の削除に関するパフォーマンスの微調整はありますか?

編集

例を次に示します。UserExclusionsEvaluate は実際には CTE であるため、プロットはより厚くなりますが、最初にテーブル変数を中心に最適化を試みます (可能であれば)。CTE 自体は非常に高速に実行されます。削除が遅いだけです。

DELETE FROM @UsersCriteria
FROM @UsersCriteria UsersCriteria
WHERE UserId IN (SELECT UserID FROM UserExclusionsEvaluate WHERE PushRuleExclusionMet = 1)

現在の化身では、 @UsersCriteria は次のとおりです。

DECLARE @UsersCriteria TABLE
(
    UserId int primary key,
    PushRuleUserCriteriaType int
)

@UsersCriteria を非プライマリとして試し、クラスター化された非クラスター化で実験しました。

また、IN に問題がある可能性もあります。サブクエリでJOINも試しました。

編集：

グッドニュース！ suquery をチェーンされた CTE に移動したり、テーブル ヒントを試したりするなど、SQL でたくさん遊んだ後。

テーブル変数から一時テーブルに変更するだけで、パフォーマンスが劇的に向上しました。

これは非常に興味深いことです。削除は単独で正常に実行され、(CTE の) サブクエリは単独で正常に実行されました。しかし、2つを混合すると非常に遅くなりました。

サブクエリで CTE を使用すると、オプティマイザが起動できないのではないでしょうか? たぶん、削除と混合したとき。

4

3 に答える 3

4

あまり。

DECLARE で動作する可能性のある PK を定義しない限り: テーブル変数の統計はなく、テーブルには 1 行のみがあると想定されます。

于 2011-08-22T18:09:12.153 に答える
3

まあ、できる量には限りがあります。ただし、テーブル変数に大きなデータ セットがある場合、パフォーマンスを向上させる必要がある場合は、代わりに一時テーブルを使用する必要があります。

バッチで削除を行うこともできます (一度に 1000 など)。

それ以外の場合は、削除ステートメントを見せてください。改善できるものがあるかどうかを確認します.

于 2011-08-22T18:10:54.470 に答える
1

番号。

テーブル変数はインデックス付けできず、一時的です。彼らには統計がありません。

非常に大量のデータを保存するためのものではありません。

テーブル変数から削除するとパフォーマンスの問題が発生するほど大きなテーブル変数がある場合は、それらを意図しない方法で使用しています。そのデータを#Tempテーブルまたは実際のテーブルに入れて、より詳細に制御できるようにします。

于 2011-08-22T18:10:27.847 に答える