JOINを行うよりもHASH JOINを指定する利点

Question

通常のJOIN（SQL Serverが最適なJOIN戦略を決定する）に対してHASH JOINを明示的に実行する利点がある場合、その利点は何ですか？例：

select pd.*
from profiledata pd
inner hash join profiledatavalue val on val.profiledataid=pd.id

上記の単純なサンプルコードでは、JOIN戦略を指定していますが、「ハッシュ」を省略すると、キーワードSQL Serverは、舞台裏でMERGE JOINを実行します（「実際の実行計画」に従って）。

Answer 1

オプティマイザーは、毎日の使用に十分な仕事をします。ただし、理論的には、極端な完璧な計画を見つけるには3週間かかる場合があるため、生成された計画が理想的ではない可能性があります。

非常に複雑なクエリや、適切なプランを作成できないような大量のデータがない限り、そのままにしておきます。それから考えます。

しかし、時間が経つにつれて、データの変更/増加、インデックスの変更などに伴い、JOINヒントは廃止され、最適な計画が妨げられます。 JOINヒントは、その一連のデータを使用して、開発時にその単一クエリに対してのみ最適化できます。

個人的に、本番コードでJOINヒントを指定したことはありません。

通常、クエリを変更したり、インデックスを追加/変更したり、分割したりして（たとえば、最初に一時テーブルを読み込む）、不適切な結合を解決しました。または、クエリが間違っているか、暗黙的なデータ型変換を行っているか、スキーマの欠陥などを強調しています。

他の開発者がそれらを使用しているのを見たことがありますが、複雑なビューにネストされた複雑なビューがあり、リファクタリング時に後で問題が発生しました。

編集：

私は今日、一部の同僚がそれらを使用して不正なクエリプラン（NOLOCKおよびMAXDOP 1を使用）を「奨励」するよう強制する変換を行いました。ダウンストリームシステムの1つが直接呼び出す従来の複雑なネストされたビューからの移行。

Answer 2

ハッシュヒントを試すとき、どうですか：

• 適切なインデックスが少なくとも1つに存在することを確認した後、 テーブル。
• クエリを再配置しようとした後。変換のようなもの 「に」に参加します;または「存在する」、結合順序の変更（これは実際に とにかくヒント）、where句から条件を結合するなどにロジックを移動する

ハッシュ結合が有効になるタイミングに関する基本的なルールは、結合条件がテーブルインデックスとして存在しない場合と、テーブルサイズが異なる場合です。技術的な説明を探している場合は、ハッシュ結合の仕組みについての良い説明があります。

結合ヒント（強制順序の副作用を伴うハッシュ/マージ/ループ）を使用する理由

• 極端なケースの実行（.5-＆gt; 10.0s）が極端に遅くなるのを避けるため。
• オプティマイザが一貫して平凡な計画を選択する場合。

提供されるヒントは、状況によっては理想的ではない可能性がありますが、より一貫して予測可能なランタイムを提供します。ヒントを使用する場合、予想される最悪の場合と最良の場合のシナリオを事前にテストする必要があります。予測可能なランタイムは、たとえば[.25、10.0s]の範囲のクエリよりも厳密に最適化された公称[.3s、.6s]クエリが優先されるWebサービスにとって重要です。統計が新たに更新され、ベストプラクティスが従うと、実行時に大きな差異が発生する可能性があります。

開発環境でテストするときは、「チート」をオフにする必要があります。また、ホット/コールドランタイムの変動を回避します。別の投稿 ...

CHECKPOINT -- flushes dirty pages to disk
DBCC DROPCLEANBUFFERS -- clears data cache
DBCC FREEPROCCACHE -- clears execution plan cache

最後のオプションは、option（recompile）ヒントと同じ場合があります。

MAXDOPとマシンのロードも、実行時間に大きな違いをもたらします。 CTEの一時テーブルへの具体化も、優れたロックダウンメカニズムであり、考慮すべき事項です。

Answer 3

ハッシュ結合は、他のどの結合よりも並列化および拡張性に優れており、データウェアハウスでのスループットの最大化に優れています。

Answer 4

出荷コードで私が見た唯一のヒントは、OPTION（FORCE ORDER）でした。 SQLクエリオプティマイザーの愚かなバグは、フィルターされていないvarcharと一意の識別子を結合しようとするプランを生成します。 FORCE ORDERを追加すると、最初にフィルターが実行されます。

列のオーバーロードが悪いことはわかっています。時々、あなたはそれと一緒に暮らさなければなりません。

Answer 5

論理計画最適化ツールは、最適なソリューションを見つけることを保証しません。正確なアルゴリズムは、運用サーバーで使用するには遅すぎます。代わりに、いくつかの貪欲なアルゴリズムが使用されています。

したがって、これらのコマンドの背後にある理論的根拠は、最適化者が実際に採用するのに最適なものを選別できない場合に、ユーザーに最適な結合戦略を指定させることです。