3

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

UPDATE Analytics
SET UserID = x.UserID
FROM Analytics z 
INNER JOIN UserDetail x ON x.UserGUID = z.UserGUID

推定実行プランは、テーブル更新で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を実行しています。上記の統計は、推定実行計画です。

4

2 に答える 2

10

すべてのクエリに LOOP ヒントを適用するのが悪い考えである理由を教えてください。LOOP JOIN がクエリオプティマイザーのデフォルトの JOIN メソッドであるとどこかで読みましたが、ステートメントの有効性を確認できませんでしたか?

これは、オプティマイザーがより効率的な他の方法を検討する機会を奪うからです。

JOIN ヒントはいつ使用されますか? ファンが大騒ぎし、ゴーストバスターズが町にいないときは？

データ分布 (オプティマイザーが決定を下す) が著しく歪んでおり、統計がそれを正しく表現できない場合。

LOOP、HASH、MERGE ヒントの違いは何ですか? BOL は、MERGE が最も遅いように見えると述べていますが、各ヒントのアプリケーションは何ですか?

これらは異なるアルゴリズムです。

  1. LOOPネストされたループ: 外部テーブルの各レコードに対して、内部テーブルで一致するものを検索します (使用可能なインデックスを使用)。両方のテーブルのレコードのごく一部のみがJOINおよび のWHERE条件を満たしている場合に最も高速です。

  2. MERGE両方のテーブルを並べ替え、一致しないレコードをスキップして、並べ替え順序でトラバースします。FULL JOINs で、両方のレコードセットが既に並べ替えられている場合 (以前の並べ替え操作から、またはインデックス アクセス パスが使用されている場合) に最速

  3. HASHテーブルの 1 つから一時ストレージ (メモリまたはtempdb) にハッシュ テーブルを構築し、他のテーブルから各レコードを検索します。いずれかのテーブルのレコードの大部分がWHEREandJOIN条件に一致する場合、最速です。

于 2010-03-15T12:18:25.443 に答える
2

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

確かにそれはあなたの提案された計画がより悪いことを意味しますか？テーブルの更新に一定の時間がかかると仮定すると、現在、インデックスアクティビティによってコストが削減されています。

于 2010-03-15T12:22:26.323 に答える