問題タブ [join-hints]

私はこれについて非常に混乱しています。最終的なSQLステートメントが動的に構築され、多くの関数とプロシージャがこれに関与しているため、例を提供できません...

一般的に、私は5つの結合を持っています。それらの1つを削除すると、ステートメントが0秒間実行され、それ以外の場合は4分以上実行されることに気付きました。次に、実際の実行プランを調べたところ、「マージ結合」には多くのコストがかかることに気付きました。Googleで検索すると、または「OPTION（MERGE JOIN）」を使用して「INNERMERGE JOIN」が表示され、ステートメントが終了します。

クエリが0秒間実行されるので、これは本当に良かったです。しかし、私の質問はなぜですか？

少し調べてみたところ、MERGE結合を使用するには、2つのステートメントを並べ替える必要があることがわかりました。これは私の場合ではなく、そうではなく、0秒で正しい結果が得られます。

なぜこれが発生する可能性があるのか​​、T-SQLのアイデアを進歩させた人はいますか？

私はすでに解決策を持っていることを知っていますが、なぜこれが機能しているのか、そして何が起こっているのかを知りたいです。

システムには、使用している論理読み取りの量に問題があるクエリがあります。クエリは頻繁に (1 日に数回) 実行されますが、本質的にレポートです (つまり、データを収集するため、トランザクションではありません)。

数人に見てもらった後、いくつかの異なるオプションを検討しています。

1. OPTION (FORCE ORDER) といくつかの MERGE JOIN ヒントを使用して、オプティマイザーがデータをより効率的に処理できるようにします (少なくともテスト済みのデータでは)。

2. 一時テーブルを使用してクエリを分割し、オプティマイザーが非常に大きなクエリを処理しないようにして、より効率的に処理できるようにします。

スキーマの大幅な変更などを行うオプションは実際にはありません。クエリのチューニングは、この問題の集結点のようなものです。

クエリ ヒント オプションのパフォーマンスは他のオプションよりも若干優れていますが、現時点ではどちらのオプションもパフォーマンスの観点からは許容範囲内です。

そこで問題は、あなたはどちらが好きですか? クエリ ヒントは、オプティマイザーなどをオーバーライドしているため、少し危険と見なされます。一時テーブル ソリューションは、tempdb などに書き出す必要があります。

過去に、大規模なレポート クエリで一時テーブルを使用して大幅なパフォーマンスの向上を確認できましたが、これは一般的に、このクエリよりも実行頻度の低いクエリの場合に見られました。

(質問: sql サーバーのチューニング - ビュー。申し訳ありませんが、投稿を確認する必要がありました)。

この投稿で最後に言及したクエリのように、結合 (結合を行うときに ID にインデックスを使用することを強制する) と選択 (where 句の名前にインデックスを使用することを強制する) にヒントを追加する必要があります。ビューから選択しているときに、結合を適切に行う正しい構文 (チューニング用) と、その where 句がそれを使用する強制インデックスの正しい構文は何かわかりません。

SQL Server 2012 で次のようなビューを作成しました。

table1 と table2 の結合が正しいインデックス (id) になるようにしたいのですが、そうすると:

最後の選択が列「名前」のインデックスになることを望みます。

私が説明したように、最適な実行を行うヒント (チューニング) を使用した SQL Server の正しい構文は何ですか?

結合目的のみ (列 = id) にインデックスを強制的に使用し、実行時にインデックス名を強制したい:

何かのようなもの

ビューを実行するときに、ビューを使用するエンドユーザーにヒントを追加することを強制したくありません。適切なインデックスヒントを使用して、ビューを自分のものとして持ってくるだけです。（または、それが不可能な場合はどうすればよいですか）。

サンプルが必要です。

私はそのような単純なビューを持っています (テーブルが何に基づいているかに関係なく...それは私が働いている会社のために非常に指定されています.これは Microsoft Dynamics AX 2012 + いくつかの追加のテーブルです)。

私がする時：

inventTable に itemid のインデックスがあっても、多くの時間がかかります。

私がする時：

ビューは数秒間実行されます。

結合ヒント（MERGE、HASH、LOOP、REMOTE）の違いを知りたい。では、どのような状況で、どの状況で、どのような理由で行うべきなのでしょうか? どのヒントを使用すればよいかを知る方法は?

ヒントを使用することの賛否両論はありますか?

正しいヒントを使用すると、クエリのパフォーマンスは向上しますか? 悪いところもありますか？

また、これらのヒントを使用する際に何か制限はありますか?

以下で説明するクエリの動作の違いについては明確ではありません。

具体的には、の概念については不明ですOPTION(LOOP JOIN)。

1 番目のアプローチ:これは従来の結合であり、以下のすべてよりもコストがかかります。

2番目のアプローチ:ソートされたデータを含むステートメントに含まOPTIONれ、単に最適化されています。

3 番目のアプローチ:ここでは、クエリがどのように機能し、!!? が含まれているかが明確ではありませOPTIONんloop join。

違いや働き方、それぞれの利点を説明できる人はいますか?

注:これらはネストされた OR ハッシュ ループではありません。