SQL Server流出レベル0-それは何ですか？
SQL Server 2016 SP2でクエリのパフォーマンスを調査するように依頼されましたが、これまでに見たことのないものを見つけました。
<Warnings>
<SpillToTempDb SpillLevel="0" SpilledThreadCount="1" />
<ExchangeSpillDetails WritesToTempDb="237" />
</Warnings>
「流出レベル0」に関する情報はありますか？
誰もがlmgtfy.comに私を送り出す前に-私はそこに行ったことがある:-)そして、Googleには文字通りこれだけの結果があります。そのページには「流出レベル0」と記載されていますが、その他の情報は記載されていません。
SQL Serverの内部の本、Bing.comなどを調べました。何もない。
私の推測では、制御スレッドのスピルオーバー、またはクエリ内のデッドロックと関係があるのではないでしょうか。クエリ自体はかなり基本的です。 3つの内部結合を持つSELECT DISTINCTと、それに続く2つのLEFT。
手がかりは大歓迎です。
そして注意してください：クエリのパフォーマンスは修正されましたが、流出の謎は残っています。私はこのクエリを改善するための助けを求めていません-そのため、ここには含まれていません。私は単に流出0についての考えを知りたいです。
環境：SQL Server 2016 Ent。 SP2（CUなし）。 MAXDOP = 4はRGによって設定されています。SSMSv18.5
また、これら2つのオペレーターのスクリーンショットも計画に含めています。
ありがとうございました！
エクスチェンジスピル （ExchangeSpillDetails）は クエリ内並列処理デッドロック に応答してのみ発生します。 SQL Serverは、1つ以上の交換（並列処理演算子）にそのバッファーをtempdbに書き込むように強制することにより、デッドロックを解決します。
交換スピルのスピル「レベル」の概念はありません（ソートまたはハッシュスピルとは異なり、複数のパスまたは再帰が必要になる場合があります）。未入力の値はゼロとして報告されます。
通常、並列デッドロックはリソースモニターによって解決されるため、回避することをお勧めします。リソースモニターは、デフォルトでは5秒ごとにのみ起動します。最近のデッドロック（何らかの種類の）があった場合は、それよりも頻繁にデッドロックをチェックしますが、パフォーマンスに優れていることは決してありません。
もう1つの一般的な注意：並列デッドロックは、スレッド間の依存関係が原因で発生し、ほとんどの場合、保存された順序に関連しています。両方の入力で順序を維持する交換を使用した並列マージ結合は、この良い例です。
クエリ内並列デッドロックのクールな視覚化については、フォレストマクダニエルの ポールホワイトパラレルデッドロックのデモ を参照してください。