15

通常のJOINよりも明示的にHASHJOINを実行することの利点は何ですか（SQL Serverが最適なJOIN戦略を決定します）。例えば：

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

上記の単純なサンプルコードでは、JOIN戦略を指定していますが、「ハッシュ」キーワードを省略した場合、SQL Serverはバックグラウンドで（「実際の実行プラン」に従って）MERGEJOINを実行します。

4

5 に答える 5

15

optmiserは、日常の使用に十分な機能を果たします。ただし、理論的には極端に完璧な計画を見つけるのに3週間かかる可能性があるため、生成された計画は理想的ではない可能性があります。

非常に複雑なクエリや大量のデータがあり、それが単に良い計画を立てることができない場合を除いて、私はそれをそのままにしておきます。それなら私はそれを検討します。

ただし、時間の経過とともに、データの変更/増加やインデックスの変更などにより、JOINヒントは廃止され、最適な計画が妨げられます。JOINヒントは、開発時に、使用しているデータセットを使用した単一のクエリに対してのみ最適化できます。

個人的には、プロダクションコードでJOINヒントを指定したことはありません。

私は通常、クエリを変更したり、インデックスを追加/変更したり、インデックスを分割したりすることで、不正な結合を解決しました（たとえば、最初に一時テーブルをロードします）。または、クエリが間違っていたか、暗黙のデータ型変換があったか、スキーマの欠陥などが強調されていました。

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

編集：

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

于 2009-04-29T04:08:59.173 に答える
3

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

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

ハッシュ結合が有効な場合の基本的なルールは、結合条件がテーブルインデックスとして存在しない場合と、テーブルのサイズが異なる場合です。技術的な説明を探している場合は、ハッシュ結合がどのように機能するかについての良い説明がいくつかあります。

結合ヒント（強制順序の副作用を伴うハッシュ/マージ/ループ）を使用するのはなぜですか？

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

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

開発環境でテストする場合は、実行時のホット/コールドの変動を回避するために、「不正行為」もオフにする必要があります。別の投稿から...

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

最後のオプションは、option（recompile）ヒントと同じである可能性があります。

MAXDOPとマシンのロードも、実行時に大きな違いを生む可能性があります。CTEを一時テーブルに具体化することも、優れたロックダウンメカニズムであり、考慮すべき点です。

于 2013-03-20T19:36:57.680 に答える
2

ハッシュ結合は、他のどの結合よりも並列化とスケーリングが優れており、データウェアハウスのスループットを最大化するのに最適です。

于 2009-04-28T23:04:13.290 に答える
1

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

私は知っている、列のオーバーロードは悪いことです。時々、あなたはそれと一緒に暮らす必要があります。

于 2009-04-29T16:57:39.153 に答える
0

論理計画オプティマイザーは、最適なソリューションを見つけることを保証しません。正確なアルゴリズムは、実動サーバーで使用するには遅すぎます。代わりに、いくつかの欲張りアルゴリズムが使用されます。

したがって、これらのコマンドの背後にある理論的根拠は、オプティマイザーが実際に採用するのに最適なものを分類できない場合に、ユーザーが最適な結合戦略を指定できるようにすることです。

于 2009-04-28T23:03:54.540 に答える