sql-server - Hints in Sql Server

Question

Are hints really necessary for every sql statement? We have a dba who is anal about it and asks us to put hints on every select and update statements in our stored procs. Is this really necessary?

Answer 1

通常ではありません。それらをすべてに置くことはやり過ぎのように聞こえます。

ドキュメントには

SQL Serverクエリオプティマイザは通常、クエリに最適な実行プランを選択するため、join_hint、query_hint、およびtable_hintは、経験豊富な開発者およびデータベース管理者による最後の手段としてのみ使用することをお勧めします。

Answer 2

あなたのDBAは間違っています。

MSから：

SQL Serverクエリオプティマイザは通常、クエリに最適な実行プランを選択するため、 結合ヒント、クエリヒント、および テーブルヒントは、経験豊富な開発者およびデータベース管理者による最後の手段としてのみ使用することをお勧めします。

Answer 3

ヒントは単なるヒントです。これらは、オプティマイザが可能な限り最高の仕事をするのに役立ちます。ただし、他の最適化と同様に、実際に問題となるステートメントに焦点を当てる必要があります。

Answer 4

通常、これは逆方向です。ただし、状況によっては望ましい場合があります。

たとえば、1つのデータベース（実際には1つのサーバー上のデータベースのセット）があり、データはすべてメインフレームシステムの夜間のスナップショットダンプであり、レポートやその他の目的に使用されます。毎晩データベースを再作成するバッチプロセスを除いて、このシステムへの書き込みは行われません。そのコンテキストでは、デフォルトのロックスキームは適切ではなく、私たちのグループとすべてのサーバーを管理するITグループとの間の政治により、私たちはそれを変更できません。つまり、これらのデータベースへのほとんどすべてのクエリにwith (nolock)ヒントがあります。

書き込みのないレポートデータベース、またはその逆の状況が他にもあると思います。アーカイブまたはログデータベースがほとんど読み取られない場合です。重要なのは、デフォルトのロック方式が適合せず、変更できない特殊なデータベースが設定される場合があるということです。次に、たくさんのピニャータが必要になります...つまりヒントです。

しかし、それはルールを証明する例外です。一般に、データベースオプティマイザは、ロックなどに関しては、あなたよりも賢いです。

Answer 5

依存 - クエリ オプティマイザは、かなり適切な意図の選択を行います。DBA が要求するヒントは何ですか? @Ned は少し間違っています。ヒントはオプティマイザーにパスを把握しないように明示的に指示しますが、代わりに最適化を使用します。

ヒントを常に使用するか絶対に使用しないかを規定することは、解決するためにヒントが存在する問題をいくらか無知にしています。ヒントが重要な場合:

• NOLOCK を使用して、トランザクション内で照会されたドメイン ルックアップ テーブルから読み取りロックを明示的に削除します。
• 大量の更新中に統計が「ドリフト」するため、クエリプランを特定のインデックスに釘付けにする (この例では、プランはクラスター化インデックスを使用するよりも 10m 行のテーブルでテーブルスキャンに戻りました)

結合ヒントを使用する必要はありませんでした。