UNION ALL は UNION よりも優れたパフォーマンスを発揮するはずであることを私は知っています (参照: union と union all のパフォーマンス)。
今、私はこの巨大なストアド プロシージャ (多くのクエリを含む) を持っています。最終的な結果は、それらの間に UNION を持つ 2 つのセクションの SELECT です。両方のデータセットは互いに外部であるため、より優れていると思われる UNION ALL を使用できます (個別の操作はありません)。
私はいくつかのデータベースでそれをチェックしましたが、うまくいきました。問題は、顧客の 1 人がパフォーマンス チューニング用にデータベースを提供してくれたことです。調査したところ、UNION ALL を UNION に変更すると、パフォーマンスが少し向上することに気付きました (!)。これが、ストアド プロシージャで行ったすべての変更です。
誰かがこの状況がどのように発生するかを説明できますか???
ありがとう、
ジヴ
更新：
両方のクエリの実行計画を添付（差分部分）：
この記事を指し示す別のトピックを参照しました。
ここをチェックすると、2 つの異なる実行計画が表示されます。大きな違いは、Distinct Sortパフォーマンスが低下したことです。
あなたの例では、2 つの実行計画には物理操作 Merge Join を含む同じステップがあります (論理操作のみが異なります)。見積もりも同じです。
今、私は本当に好奇心旺盛です.2つのクエリの違いはどれくらいですか?
次のことを行っていない場合は、もう一度テストを繰り返してください:
1) PRC を実行する前に次の行を使用します。
DBCC FREEPROCCACHE
DBCC DROPCLEANBUFFERS
これにより、キャッシュがクリアされ、どちらの場合も「コールドラン」を実行できます。ここでも他の記事をチェックできます。
2) 実行を数回繰り返して、平均値を確認します。
違いはまだありますか？
これは、重複する行がある場合に発生する可能性があります。UNION ステートメントは、結果セットに対して SELECT DISTINCT を効果的に実行します。返されるすべてのレコードがユニオンから一意であることがわかっている場合は、UNION ALL を使用すると結果が速くなります。ただし、あなたの場合の重複については、UNIONを高速化するのに十分な数の重複があると推測します-これをテストして、重複を数えてそれらを削除できます。その後、UNION ALL を実行すると、「勝者」に戻る可能性があります...
これが役立つことを願っています。