0

システムには、使用している論理読み取りの量に問題があるクエリがあります。クエリは頻繁に (1 日に数回) 実行されますが、本質的にレポートです (つまり、データを収集するため、トランザクションではありません)。

数人に見てもらった後、いくつかの異なるオプションを検討しています。

  1. OPTION (FORCE ORDER) といくつかの MERGE JOIN ヒントを使用して、オプティマイザーがデータをより効率的に処理できるようにします (少なくともテスト済みのデータでは)。

  2. 一時テーブルを使用してクエリを分割し、オプティマイザーが非常に大きなクエリを処理しないようにして、より効率的に処理できるようにします。

スキーマの大幅な変更などを行うオプションは実際にはありません。クエリのチューニングは、この問題の集結点のようなものです。

クエリ ヒント オプションのパフォーマンスは他のオプションよりも若干優れていますが、現時点ではどちらのオプションもパフォーマンスの観点からは許容範囲内です。

そこで問題は、あなたはどちらが好きですか? クエリ ヒントは、オプティマイザーなどをオーバーライドしているため、少し危険と見なされます。一時テーブル ソリューションは、tempdb などに書き出す必要があります。

過去に、大規模なレポート クエリで一時テーブルを使用して大幅なパフォーマンスの向上を確認できましたが、これは一般的に、このクエリよりも実行頻度の低いクエリの場合に見られました。

4

1 に答える 1

1

インデックスによる最適化を使い果たし、SARGABLE 以外の SQL を削除した場合は、一時テーブル オプションを使用することをお勧めします。

  1. サイズの増加とパフォーマンスの点でtempdbに過度の圧力をかけない限り、一時テーブルは再現可能なパフォーマンスを提供します-それらを監視する必要があります
  2. 将来的に他のテーブル/インデックスが変更されるため、SQL ヒントが有効でなくなる可能性があります。
  3. 終了したら、忘れずに一時テーブルをクリーンアップしてください。
于 2012-11-14T16:22:29.647 に答える