問題タブ [join-hints]

同僚から、クエリの実行時間が非常に長いため、いくつかのテーブルのインデックス作成を調べるように依頼されました。1時間以上。

異なるデータベースに注意してください。これは DatabaseB から実行されていました

テーブル 1 と 2 は、200 万を超えるレコード長でした。Table3 には 10 ほどのレコードがありました。

クエリ プランを調べたところ、オプティマイザは、Table3 を駆動テーブルとして、テーブル 1 と 2 へのネスト ループ インデックス シークを実行することにしました。

私の最初の仮定は、Tables1 と 2 で統計がひどく台無しになっているということでしたが、統計を更新する前に、次のように結合ヒントを追加しようとしました。

結果は 15 秒で返されました。

時間がなかったので、結果を彼に返しましたが、これが後で問題になるのではないかと心配しています.

統計の問題を再検討して、その方法で問題を解決する必要がありますか? 別のデータベースからの結合が原因で、不適切なクエリ プランが発生した可能性はありますか?

あなたの経験に基づいて誰かが私にいくつかのアイデアを提供できますか?

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

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

一部の SQL Server ビューにアクセスするアドホック レポート ユーザーがいます。場合によっては、これらのユーザーが特に長いクエリのために取得した読み取りロックにより、システムの他の場所で問題が発生することがあります。

ビューに戦略的なヒントを追加することを検討with(nolock)していますが、ビューのヒントに関連する落とし穴があるかどうかを知りたいと思っていました。

ユーザーが SQL メタルの近くでクエリを実行できるようにすることに関する明らかな問題は無視してください :)。

また、nolock ヒントは軽々しく使用してはならない高度な機能であることを知っており、ダーティ リードなどの楽しい機能が導入されていることも十分に認識しています。最後に、ここで read_committed_snapshot が理にかなっているとお考えの場合は、残念ながら 2000 では利用できないと言わざるを得ません。

最近、私はこのクエリを最適化しようとしていました

推定実行プランは、テーブル更新で57％、ハッシュ一致（集計）で40％を示しています。私はいくつかの詮索をして、JOINヒントのトピックに出くわしました。そこで、内部結合とWA-ZHAMにLOOPヒントを追加しました。新しい実行プランでは、テーブルの更新で38％、インデックスシークで58％が表示されます。

ですから、慎重さが良くなるまで、すべてのクエリにLOOPヒントを適用し始めようとしていました。少しグーグルした後、JOINのヒントがBOLで十分にカバーされていないことに気付きました。したがって...

1. 誰かが私のすべてのクエリにLOOPヒントを適用することが悪い考えである理由を教えてもらえますか？LOOP JOINがクエリオプティマイザーのデフォルトのJOINメソッドであるとどこかで読みましたが、ステートメントの有効性を検証できませんでしたか？
2. JOINヒントはいつ使用されますか？sh * tがファンにぶつかり、ゴーストバスターが町にいないときは？
3. LOOP、HASH、MERGEのヒントの違いは何ですか？BOLは、MERGEが最も遅いように見えると述べていますが、各ヒントの適用は何ですか？

あなたの時間をありがとう、そして人々を助けてください！

私はSQLServer2008BTWを実行しています。上記の統計は、推定実行計画です。

クイックノート

そのため、以下に問題を書いているときに、自分で修正する方法を見つけました。次の理由から、私はまだ質問を投稿すると思いました。

1. 誰かがそれを便利だと思うかもしれません。
2. なぜそれが機能するのかあまりわかりません。

とにかく固定コード（回答を参照）。

私はもともと書いた：

私はこれをグーグルで何年も費やしてきましたが、関連する多くの回答を見つけることができますが、私の質問と完全に一致するものはありません.

以下のコードを SQL Server (10) データベースに対して実行すると、非常に高速に実行されます。使用する実行計画には、ハッシュ結合が含まれます。

次に、もう一度実行しますが、今回は最初の 2 行 (DECLARE と SET 行) のコメントを外し、y.[in date] の横にある '+1' も削除し、'+ @COUNTER' のコメントも外します。現在、クエリが完了するまでに (時間の経過に応じて) 時間がかかります。代わりに、ネストされたループを使用する実行計画です。まだ日付に 1 を追加しているだけですが、定数の代わりに変数を使用していることに注意してください。

問題は、@COUNTER を使用したクエリで、ネストされたループの代わりにハッシュ結合を使用できるかどうかです。

(ちょっとした背景: 私がやろうとしているのは、x.[in date] と y.[in date] を大まかに一致させて、指定された日数以内であれば一致するようにすることです。使用するクエリの日数は、別のテーブルのフィールドから入力されます. 最初に abs() と未満で datediff() を使用しようとしましたが、常にネストされたループを使用することになると確信しています. (試してみるとそうです.とにかく！）

さまざまなパラメータ スニッフィングの記事で言及されているすべてのことを試してみましたが、状況は変わりませんでした。とにかく、これをストアドプロシージャとして実行していません。[in date] フィールドのインデックスと何か関係があると思います。)

ハッシュ ヒント結合を明示的に使用する場所を知るにはどうすればよいですか? クエリオプティマイザーがだまされてヒントを適用し、パフォーマンスに影響を与えることがあるのはどのようにですか?

今日、私はSQLServerで。と呼ばれるものについて学びましたINNER LOOP JOIN。

これは何を意味するのでしょうか？（グーグルは助けていない..または私が言うべきである...それについてのブログ投稿は少し..技術的であり、私の心を吹き飛ばしている）。

INNER LOOP JOINまた、標準を超えて使用することをお勧めするいくつかの一般的なシナリオは何INNER JOINですか？

インデックスが破損しているように見えるものがありますか?

これが何が起こっているかです。私は 2 つのテーブル関数を持っています。1 つ目はケースのセットで、2 つ目は日付のセットです。これらの 2 つのセットには、1 (ケース) 対 0 または 1 (認識日) の関係があります。通常、私はそれらを次のようにクエリします。

問題は、一致する AwareDates のすべての行が JOIN されているように見えないことです。結合ヒントを追加すると、それらは実行されます。いう;

クエリ プランから気付いたのは、結合ヒントを追加すると、結合の前に AwareDate データの一種が追加されることです。これは、他の方法では存在しません。また、クエリ プランナーは、ヒントがない場合、結合を RIGHT OUTER JOIN に切り替えます。もちろん、ヒントが存在する場合は LEFT JOIN を保持します。

エラーが検出されずに次のことを行いました。

私は困惑しています...何かアイデアはありますか？

UDF の定義は次のとおりです。

さらに、「WITH (NOLOCK)」テーブル ヒントを削除すると、正しい結果が得られることがわかりました。また、結合ヒントを AwareDates UTF に追加するか、イニシャルとリセットの間の LEFT JOIN 関係に COLLATE Latin1_General_BIN を追加する場合。

クエリ プランの行数 -- 結合ヒントなし (破損)

• ケース { 実績: 25,891、推定: 19,071.9 }
• AwareDates { 実際: 24,693、推定: 1,463.09 }
  • イニシャル { 実際: 24,693、推定: 1,463.09 }
  • 残り { 実際: 985、推定: 33.2671 }
• AwareDates は、結合された結果セットの 8,108 行の Cases と一致します

クエリ プランの行数 -- 結合ヒントあり (動作中)

• ケース { 実績: 25,891、推定: 19,071.9 }
• AwareDates { 実際: 24,673、推定: 1,837.67 }
  • イニシャル { 実際: 24,673、推定: 1,837.67 }
  • 残り { 実際: 982、推定: 42.6238 }
• AwareDates は、結合された結果セットの 24,673 行の Cases と一致します

問題の範囲をさらに絞り込みました。できます;

と

行数が異なります。

私のgoogle-fuとso-fuはここで失敗しているので、質問した方がいいかもしれません.

複数の結合を含む多くのクエリがあります。

1 つのクエリ内で、ヘッダー/アイテム/詳細を結合し、これらのレコードのさまざまな情報を検索します。

参加するときは、物事がどのように関連しているかを整理するようにしています。例: 私のヘッダーには 2 つのルックアップ テーブルがあるので、アイテム テーブルに結合する前にそれらに結合します。

あれは正しいですか？

ルックアップ テーブルの前に、より大きなテーブルに結合する方がよいでしょうか? それともその逆？

loop小さなテーブルに参加するときはヒントを使用し、mergeopenrowset に参加するときはヒントを使用する必要がありますか?

答えは「場合による」と思いますが、効果的かつ効率的に参加するための一般的なガイドラインがあれば非常に役立ちます。ありがとう！