6

クエリを実行し、実際の実行プランを含めました。サブツリーがインデックスシークの代わりにインデックススキャンを使用するため、私が興味を持っているハッシュマッチが1つあります。このハッシュマッチにマウスを合わせると、「ProbeResidual」というセクションがあります。私はこれが私が参加しているどんな価値観でもあると思っていました。私はここで正しいですか、それともそれが何を意味するのかについてのより良い説明がありますか?

私が持っていた2番目の質問は、それが使用するインデックスに関するものです。私の例では、この特定の結合が2つの列で結合していると確信しています。スキャンしているインデックスには、これらの列の両方と、結合で使用されていない別の列が含まれています。これにより、スキャンではなくインデックスシークが発生するという印象を受けました。私はこれを間違えていますか?

4

4 に答える 4

4

ハッシュ結合は、通常 (常に?) スキャンまたは少なくとも範囲スキャンを使用します。ハッシュ結合は、左右の結合テーブル (またはテーブル内の範囲) をスキャンし、スキャンによって「見られる」すべての値を含むメモリ内ハッシュ テーブルを構築することによって機能します。

あなたのケースで起こったことは次のとおりです。QO は、たまたまこの列を (キーまたは含まれる列として) 含む非クラスター化インデックスから列 C のすべての値を取得できることに気付きました。非クラスター化インデックスであることはおそらくかなり狭いため、非クラスター化インデックス全体をスキャンするための IO の合計量は誇張ではありません。また、QO は、ハッシュ テーブルをメモリに格納するのに十分な RAM がシステムにあることも考慮しました。このクエリのコスト (たとえば 10000 ページの非クラスター化インデックスのエンド ツー エンドのスキャン) と、シークを使用したネストされたループのコスト (それぞれ 2 ~ 3 ページで 5000 プローブ) を比較すると、 scan は、必要な IO が少ないとして勝ちました。もちろん、主に私の推測ですが、QO の観点からケースを提示しようとしており、計画はおそらく最適です。

この特定のプランの選択に寄与した要因は次のとおりです。

  • 結合の右側にある多数の推定候補
  • 左側の狭い非クラスター化インデックスでの結合列の可用性
  • 十分なRAM

候補の数を大量に見積もる場合、ハッシュ結合よりも適切な選択はマージ結合のみであり、その場合は入力を事前に並べ替える必要があります。左側の両方が結合された列の順序を保証するアクセス パスを提供でき、右側も同様の可能性がある場合、最速の結合であるマージ結合になる可能性があります。

于 2010-01-21T01:09:13.263 に答える
4

このブログ投稿は、おそらく最初の質問に答えます。

2番目については、多くの状況でオプティマイザーによってインデックススキャンが選択される可能性があります。私の頭の上から:

  • インデックスが非常に小さい場合
  • インデックス内のほとんどの行がクエリによって選択される場合

  • クエリの where 句で関数を使用している場合

最初の 2 つのケースでは、スキャンを実行する方が効率的であるため、オプティマイザーはシークよりもスキャンを選択します。3 番目のケースでは、オプティマイザーには選択の余地がありません。

于 2010-01-21T01:01:28.167 に答える
2

simple-talk.comで実行計画に関する優れた記事を確認してください。

また、ダウンロード用の無料の電子書籍SQLServer実行プランもあります。

于 2010-01-21T06:32:42.763 に答える
2

1/ ハッシュ一致とは、等値結合で使用される列のハッシュを取得することを意味しますが、結合に含まれる他のすべての列 (> など) を含めて、それらもチェックできるようにする必要があります。ここで、残りの列の出番です。

2/ 必要な行に直接移動できる場合は、インデックス シークを実行できます。おそらく、列に計算を適用してそれを使用していますか? 次に、インデックスをデータの小さいバージョンとして使用しますが、すべての行をチェックする必要があります (各行に計算を適用します)。

于 2010-01-21T01:02:42.817 に答える