SQL Serverで熱心なスプール操作を回避する方法

Question

SELECT INTOステートメントを最小限に抑え、ログトラフィックの発生が少ないため、処理速度が速いストアドプロシージャを使用するETLプロセスがあります。ストアドプロシージャに格納された一連の作業の中で、最も高価な操作のいくつかは、単にクエリ結果をバッファして作成したテーブルにコピーするように見える熱心なスプールです。

eager spoolsに記載されているMSDNのドキュメントは非常にまばらです。誰にも、これらが本当に必要かどうか（そしてどのような状況下で）、より深い見識がありますか？私はいくつかの理論を持っているかもしれませんし、意味がないかもしれませんが、質問からこれらを除外することに成功しません。

.sqlplanファイルはかなり大きいので（160kb）、フォーラムに直接投稿するのはおそらく妥当ではないと思います。

• クエリは、このようなフォーマットされた日付を解析として、データ変換のためのいくつかのUDFを使用しています。

  だから、ここの特定の回答を受けやすいかもしれいくつかの説があります。このデータ変換では、感覚的な型（例：varcharの長さ）を構築する前にテーブルに割り当てるために熱心なスプールを使用する必要がありますか？

• 上記の質問の延長として、クエリでこの操作を駆動するかどうかを誰かがより深く理解できますか？

Answer 1

私のスプーリングの理解は、あなたの実行計画上の赤いひねりのビットです。はい、それはあなたのクエリコストの多くを占めますが、実際にSQL Serverがコストをかける再スキャンを避けるために自動的に行う最適化です。あなたがスプーリングを避けるなら、それが置かれている実行ツリーのコストは上がり、ほとんどの場合、クエリ全体のコストは増加します。私は、特にSQLコードを見ずにデータベースのクエリオプティマイザがそのような方法で構文解析を引き起こす原因について特に洞察していませんが、おそらくその動作を信頼するほうが良いでしょう。

ただし、ソースデータがどれだけ揮発しているかによって、実行計画を最適化することはできません。 SELECT INTOを実行しているときは、スプーリング項目が実行計画によく表示され、読み取りの分離に関連する可能性があります。特定の状況に適している場合は、トランザクション分離レベルを低コストに、またはNOLOCKヒントを使用してレベルを下げてみてください。複雑でパフォーマンスが重視されるクエリでは、安全で適切なデータであれば、何らかの理由がないようでもクエリの実行速度が大幅に向上することがわかりました。

この場合、READ UNCOMMITTEDまたはNOLOCKヒントを試すと、スプールの一部を削除することができます。 （明らかに、矛盾した状態になってしまう可能性がある場合は、これをやりたくはありませんが、すべてのデータの分離要件は異なります）。 TOP演算子とOR演算子はスプーリングを引き起こすことがありますが、ETLプロセスでそれらを実行しているとは思われません。

あなたのUDFもまた原因である可能性があります。一度だけ各UDFを使用している場合は、パフォーマンスを大幅に向上させるかどうかを確認するためにインラインで試してみることは面白い実験です。 （クエリでインラインで記述する方法を見つけられない場合は、おそらくスプールが発生している可能性があります）。

最後にもう一度見ておきたいことは、並べ替えが可能な結合を行っている場合、最も選択的な順序であることを知っている結合順序を強制するためのヒントを試してみることです。これはちょっとしたリーチですが、すでに最適化が固まっている場合は試してみてください。