実行時間の長いクエリを高速化しようとしています（実行に約10分かかります...）。クエリのどの部分に最もコストがかかっているかを追跡するために、実行時に実際の実行プランを含めて、55％を占めている特定のセクションを見つけました（下のスクリーンショット）
代替テキストhttp://img109.imageshack.us/img109/9571/53218794.png
これは私にはまったく正しくないように思われたので、このトラブルセクションの前後に追加Print '1'しました。Print '2'クエリをわずか17秒間実行してからキャンセルすると、1と2の印刷がキャンセルされます。これは、最初の17秒間にそのセクションを通過していることを意味すると想定しています。
代替テキストhttp://img297.imageshack.us/img297/4739/66797633.png
私はここで何か間違ったことをしていますか、それとも私の実行計画は私を誤解させていますか？
perfmonのメトリックは、何が問題になっているのかを把握するのにも役立ちます...tempDBが存在するドライブで深刻なIOの問題が発生する可能性があります。さらに、トレースを実行し、実際の実行のCPUとIOを確認します。
確認するのに適したパフォーマンスメトリックは、ディスクキューの長さ（平均と書き込み）です。
perfmonにアクセスできない場合、または追跡したくない場合は、クエリの最初に「SET STATISTICS IO ON」を使用して、クエリを完了させてください...停止しないでください。実行プランがコストを引き継ぐと言っているからといって、クエリ時間の半分で実行されるわけではありません...それははるかに多い（または少ない）可能性があります。
それは言うQuery 10: Query cost (relative to the batch): 55%。Printステートメントで囲んだのはバッチの10番目のステートメントであると100％肯定的ですか？INSERT ... INTO＃mpProgramSet2は、選択/挿入されたデータの量に応じて、複数回実行できますか？17秒未満で実行できる場合もあれば、5分間実行できる場合もありますか？
補足として、印刷ではなく実行する必要がありますSET STATISTICS TIME ON。これにより、バッチ内の各ステートメントの正確なコンパイル/時間と実行時間が得られます。
何が起こっているのかを理解するには、完全なクエリが必要です。ただし、実行するプロセッサの数を制限するために、MAXDOPを1に設定することから始めます。
ロックなどの理由で、クエリを1つのプロセッサのみに制限する必要がある場合があることに注意してください。
さらに、ダーティリードを回避できる任意の選択にNOLOCKを追加してみてください。
「1」と「2」を印刷することで、何が実行され、何が実行されなかったかについて何かが証明されるとは信じられません。私は同じことをしますが、証拠としてそれを信頼することはありません。その最初の挿入クエリから@@rowcountを出力できます。これは、挿入が行われたことを確実に示します。
計画では、クエリはコストの55％を占める可能性があると述べていますが、特にクエリ結果がキャッシュされている場合は、実行時間の55％ではない可能性があります。
@@ rowcountを出力するもう1つの利点は、実際の行数を推定行数（51K）と比較することです。それらが大きく異なる場合は、インデックスの統計を調査することができます。
