3

スケジュールされたジョブとして使用するクエリを開発しています。簡単に言うと、テーブルに対していくつかの特定の計算を行い、計算結果に従っていくつかの列 (STATE など) を更新します。

サンプル (現在の状態) は、次のように示すことができます。

UPDATE TEST_TABLE SET STATE = 1
WHERE {some condition}

UPDATE TEST_TABLE SET STATE = 2
WHERE {some condition}

UPDATE TEST_TABLE SET STATE = 3, SOME_OTHER_COLUMN={value}
WHERE {some condition}

WHILE(some condition)

BEGIN
UPDATE TEST_TABLE SET STATE = 4, SOME_OTHER_COLUMN={value}

WHERE {some condition}

END

上記で実証しようとしたのは、クエリの流れです。上に見られるように、私は単一のテーブルを複数回更新しています。ほとんどの場合、異なる条件に応じて異なる値を持つ単一の状態列を設定しています。

また、条件に応じて小さなグループでこのテーブルのデータを更新する必要があったため、(パフォーマンスが低いため) カーソルの代わりに while ループを使用する必要がありました。

すべてのクエリがトランザクションと try-catch ブロックにラップされていると仮定します。

最後に、私の質問は次のとおりです。これは夜間に実行されるスケジュールされたジョブになるため、パフォーマンスは私にとって最優先事項ではありません。ただし、もう少しクリーンで効率的な (パフォーマンス面での) クエリを使用して同じ操作を行う方法を理解できませんでした。アドバイスが必要です。{some condition} 領域は、EXISTS 機能を持つサブクエリを保持することに注意してください。したがって、元のコードはこれよりもはるかに乱雑に見えます。前もって感謝します。――オザン

4

1 に答える 1

1

テーブルが十分に小さければ、複数のクエリを実行しても問題はありません。

WHEREインデックスのためにクエリの句が効率的に機能するところまでかなり大きくても、問題ない場合があります。

クエリを統合できますWHERE。句が同じ場合は、それらをまとめることができます。

IMO、コードが読みやすいほど、維持しやすくなります。大幅なパフォーマンスの向上が得られない場合は、統合しても意味がありません。

クエリの効率は、クエリがどれだけうまく統合されているか、どれだけ複雑に見えるかではなく、消費するリソースの量で測定されます。実行計画を見て、テーブルに必要な構造上の変更やインデックスを見つけたほうがよい場合があります。

私の目を引く最大のことは、あなたが a を試して、それをループ CURSORに変更したことです。WHILE

セットベースの操作は、カーソルよりもデータベースの作業にはるかに役立ちます。

OPコメントに基づいて編集

テーブルはすぐにいっぱいになることが予想されるため、負荷テストを行う必要があります。テーブルに大量のテスト データ (たとえば 1 年分) をロードし、クエリのパフォーマンスを確認します。

于 2011-11-17T21:52:52.957 に答える