タグ付けされた質問 「hints」

ステートメントOPTION (FAST XXX)内でクエリヒントが何をするかを掘り下げましたが、SELECTまだ混乱しています。MSDNによると： クエリが最初のnumber_rowsの高速取得のために最適化されることを指定します。これは非負の整数です。最初のnumber_rowsが返された後、クエリは実行を継続し、完全な結果セットを生成します。 私にとってそれはあまり意味がありませんが、基本的にクエリは最初のXXX行を本当に速く取得でき、残りは通常の速度で取得できますか？ これについて考えさせられたMicrosoft Dynamicsクエリは次のとおりです。 select pjproj.project,pjproj.project_desc,pjproj.customer,pjproj.cpnyid from pjproj WITH (NOLOCK) where project like '%' order by project OPTION(FAST 500) 誰でもこのクエリヒントが何をしているのかを正確に説明できますか？それはそれを使用しないよりも有利です？

29 sql-server  t-sql  hints  microsoft-dynamics 

テーブルClientフィールドにクラスター化インデックスがありますLastName。 テーブルからすべてのレコードを単純にダンプすると、(nolock)問題のクエリのようにヒントが使用されていない限り、レコードはアルファベット順に表示されます。そのヒントは、レコードの順序を変更します。それをすべきですか？他のどのセッションにも、そのテーブルへの変更を伴うオープントランザクションsp_who2がないことは確かです（少なくとも私には何も表示されていません）。 順序の違いはどのように説明できますか？ コメントから引き出された追加情報： による注文はありません。非クラスター化インデックスは順序を強制する必要がありますか？ クラスター化インデックスを指定するインデックスヒントを使用する場合でも、クエリは異なる順序を返します。彼らはすべきですか？nolock返されたレコードの順序が、計画の目に見える変更なしに変更されるのはなぜでしょうか。 私はそれらに対してWinDiffを行いました-[the] (nolock)[query hint] を除いて同じです。

11 sql-server-2012  hints  order-by 

このREADPASTヒントを使用して、アプリケーションの金融サブシステムのリソースロックを削減することを調査しています。 金融取引記録は追加されるだけで、更新または削除されることはないため、良い方法のように思えました。スキップされる行は、トランザクション内に挿入された新しい行のみです。トランザクションがコミットされるまで、それらは事実上外界には存在しません。 ただし、READPASTヒントを付けたインデックス付きビューを使用するクエリのパフォーマンスが低下していることに気付きました。クエリプランを比較すると、ヒントのように見えます。クエリオプティマイザーは、インデックス付きビューを使用しないことを選択し、代わりに通常のビューのように扱います。 それがなぜかはわかりません。インデックス付きビューは、操作中にキーをロックでき、追加READPASTも同様に機能するという点で、他のインデックスと同じだと思います。 SELECT TOP 1 isa.InvoiceId FROM Financial_InvoiceSummaryAmounts isa WITH (READPAST) WHERE isa.TotalOwedAmount = 0.0 SELECT TOP 1 isa.InvoiceId FROM Financial_InvoiceSummaryAmounts isa WHERE isa.TotalOwedAmount = 0.0 NOEXPANDヒントの追加も機能するようですREADPASTが、クエリオプティマイザーがそもそもなぜ（完全な回答の一部として）選択したのか、おそらくその理由について詳しく知りたいと思います。

10 sql-server  query-performance  materialized-view  hints 

やや複雑なSQL Server 2008クエリ（約200行のかなり高密度のSQL）があり、必要なときに実行されませんでした。時間の経過とともに、パフォーマンスは約0.5秒から約2秒に低下しました。 実行計画を見ると、結合を並べ替えることでパフォーマンスが向上することは明らかでした。私はそうしました、そしてそれは...約0.3秒にまで減少しました。これで、クエリに「OPTION FORCE ORDER」というヒントが追加されました。 今日、私はデータベースをクリーンアップします。行の約20％をアーカイブし、行を削除する以外は関連するデータベースでアクションを実行しません...実行プランは完全にホースされます。特定のサブツリーが返す行数を完全に誤って判断し、（たとえば）次のものを置き換えます。 <Hash> と <NestedLoops Optimized='false' WithUnorderedPrefetch='true'> これで、クエリ時間が約0.3秒から約18秒に急上昇します。（！）行を削除したからといって。クエリヒントを削除すると、クエリ時間は約2秒に戻ります。良いが悪い。 データベースを複数の場所とサーバーに復元した後、問題を再現しました。各テーブルから行の約20％を削除するだけで、常にこの問題が発生します。 強制結合順序がクエリの見積もりを完全に不正確にする（したがってクエリの時間を予測できない）のは、これが正常ですか？ 最適ではないクエリのパフォーマンスを受け入れる必要があるか、それともタカのように見て、頻繁に手動でクエリのヒントを編集する必要があると思いますか？または、すべての結合についてもヒントがありますか？.3sから2sは大ヒットです。 行を削除した後にオプティマイザが停止した理由は明らかですか？たとえば、「はい、サンプルスキャンを実行しました。データ履歴の前半でほとんどの行をアーカイブしたため、サンプルはスパースな結果を生成したため、ソートされたハッシュ演算の必要性を過小評価していました」 実行計画を見たい場合は、投稿できる場所を提案してください。そうでなければ、私は最も素晴らしいビットをサンプリングしました。これが根本的な誤推定です。括弧内の数字は（推定：実際の）行です。 / Clustered Index Scan (908:7229) Nested Loops (Inner Join) --< \ NonClustered Index Seek (1:7229) 内部ループは908行をスキャンすると予想されますが、代わりに52,258,441をスキャンすることに注意してください。正確であれば、このブランチは12秒ではなく、約2ミリ秒で実行されたはずです。行を削除する前に、この内部結合の推定は合計係数2だけオフであり、2つのクラスター化インデックスのハッシュ一致として実行されました。

9 sql-server  sql-server-2008  query-performance  optimization  hints