問題タブ [sql-execution-plan]

クエリを最適化しようとしていますが、Explain Planから返される情報の一部がよくわかりません。OPTIONS 列と COST 列の重要性を教えてもらえますか? OPTIONS 列には、FULL という単語しか表示されません。COST 列では、コストが低いほどクエリが高速になると推測できます。しかし、コスト値は正確には何を表し、許容可能なしきい値は何ですか?

SQL Server 2005 では、次のような複雑な複数レベルの割り当てプロセスがあります (疑似 SQL)。

whereALLOCSは直接割り当てでシードBALANCES(@LVL_NUM)さALLOCSれ、@LVL_NUM(いくつかの直接割り当てと前のレベルからのいくつかの IN 割り当てである可能性があります) にALOCNS(@LVL_NUM)基づいており、に基づいてBALANCES(@LVL_NUM)おり、ALOCN_SUMRY(@LVL_NUM)単純に基づいていALOCNS(@LVL_NUM)ます - ドライバーを示す多くの構成テーブルを使用して、割り当てを追い出します。

これは単純化されていますが、実際にはループ内にこのようなペアが 4 つまたは 5 つあります。これは、一緒に処理できないさまざまなロジックがあるためです (また、一緒に処理できる場合もあります)。

基本的なロジックは、特定のコスト センター/製品ライン/その他(BALANCESつまりALLOCNS / ALLOCN_SUMRYメトリック。

OUT記録管理とで非常に多くのロジックが繰り返され、INもちろん詳細にSUMRY基づいて、ALLOCNインライン テーブル値関数を使用して実装することになりました。プラスです！）。(既存のシステムは巨大な C/C++/MFC/ODBC プログラムであり、すべてのデータを大量の配列やその他のデータ構造に読み込み、非常にひどく書かれています。)

問題は、ループで実行すると、テーブルが変化し始めるにつれてレベルを上げていくと、実行計画の問題が発生しているように見えることALLOCSです (そして、レベルには異なるコストセンターがあるため、すべてが変化しているため、構成を駆動するために使用されるものALLOCNSは変化しています)。レベルは 99 まであると思いますが、最低レベルは 2、4、6 から始まります@LVL_NUM = 6。UDF の外部で単独で実行すると問題なく動作するように見えますが、UDF のパフォーマンスは低いようです。おそらく、UDF にキャッシュされたプランがあるか、またはでのALLOCS前のステップから追加されたために、全体的な計画はすでに悪いものです@LVL_NUM IN (2, 4)。

開発の初期段階では、30 レベルを 30 分で実行できましたが、今では最初の 3 レベルを 2 時間で完了することはできません。

別の SP 内で 2 つの挿入を実行し、それを WITH RECOMPILE と呼ぶことを検討していますが、この RECOMPILE が TVF UDF に適切にカスケードされるかどうか知りたいですか? 他のアドバイスもいただければ幸いです。

実際のコード:

これは、最終的に単一の SP でプロセス全体を実行する私のテスト バッチです。コメントアウトされたセクションから、一時テーブルとテーブル変数でも遊んでいることがわかります。

2 つのインデックスを持つテーブルがあります。1 つは、3 列の複数列クラスター化インデックスです。

2 つ目はクラスタ化されていない

私が実行しようとしている選択ステートメントは次のとおりです。

SQL Management Studioエディターを使用してsql2008でこのクエリを実行し、実際の実行計画を有効にすると、SQLが2番目のインデックスと提案を使用して、3つの列（symbolid、bartime、typeid）の新しいインデックスを作成することがわかりましたが、クラスター化されていません!!! （すでにクラスター化されたインデックスがあるため、非クラスター化インデックスと言っていると思います）

この選択は間違っています。もう一度同じクエリを再実行し、SQL にクラスタ化されたインデックス ("with index" を使用) を使用させると、パフォーマンスが向上します。

ここで 2 つの質問があります。1 つはこの動作に関連し、もう 1 つはクエリ自体に関するものです。

1. SQL が間違ったインデックスを選択し、同じインデックスを提案する理由
2. "where"パフォーマンスを向上させるために、条件でどちらを使用する必要がありますか

(1010,1020,1030,1040,1050,1060) のシンボル ID

(symbolid = 1010 または symbolid = 1020 など)

((1010 と 1060) の間の記号)

テスト後

where 条件を IN の使用から >= および <= の使用に変更すると、bartime 列の非クラスター化インデックスは、3 列のクラスター化インデックスよりも優れたパフォーマンスを発揮することがわかりました。

SO WHERE が IN を使用する場合、クラスター化インデックスを使用する方が良い場合が 2 つあります。

次のSQLクエリを実行すると

WHEREステートメントは？の前または後に評価されますJOINか？

A後の場合、からの行のみが返されるようにこのステートメントを記述するためのより良い方法は何に"Yesterday"結合されBますか？

私たちのサイトはかなりの打撃を受けているため、既存のクエリのいくつかを最適化することを検討しています。

これを調べていると、クラスター化されたインデックスの単純な参照がクエリに含まれている場合、実行プランが約 4 ～ 5 倍高速であるいくつかのクエリに出くわしました...たとえば

これが古いクエリの場合:

SSMS の実行計画によると、次のクエリは 4 倍高速になります。

これがどのようにクエリを高速化するのか理解できないようです。クラスター化されたインデックスはlotIDにありますが、それ自体と比較しているため、これはどのように役立ちますか?

値が渡されない場合、後で現在の日付に設定される日付入力を受け入れるストアド プロシージャがあります。

@MyDateストアド プロシージャが最初にコンパイルされたときに渡されたNULL場合、すべての入力値 (またはそれ以外) のパフォーマンスが常にひどいという問題がありNULLますが、ストアド プロシージャがコンパイルされたときに日付/現在の日付が渡された場合すべての入力値 (NULLまたはそれ以外)のパフォーマンスは良好です。

また紛らわしいのは、使用される @MyDate の値が実際に NULL(かつCURRENT_TIMESTAMPIF ステートメントによって設定されていない)場合でも、生成される貧弱な実行計画がひどいことです。

パラメータ スニッフィングを無効にすると (パラメータをスプーフィングして)、問題が解決することがわかりました。

これはパラメーターのスニッフィングと関係があることは知っていますが、「パラメーターのスニッフィングがうまくいかなかった」という例はすべて、渡された代表的でないパラメーターを使用してコンパイルされたストアド プロシージャに関係していましたが、ここで私はそれを見ています実行計画はNULL、ステートメントが実行される時点でパラメーターが取る可能性があるとSQLサーバーが考える可能性のあるすべての考えられる値に対してひどいものです-CURRENT_TIMESTAMPまたはその他。

なぜこれが起こっているのか、誰かが洞察を得ましたか?

Oracle 10gの（空間）クエリは、パラメータ値のみに応じて異なる実行プランを取得します。そして悲しいことに、Oracleは計画の1つをまったく実行できず、エラーが発生します。値（282未満から284）または演算子（=から<）を変更すると、結果が得られます。なぜ計画が違うのですか？オラクルが実行不可能な計画を選択するのはなぜですか？Oracleに実行可能実行プランを選択させるにはどうすればよいですか？

クエリ：

エラーを与える：

実行されない計画：

実行して結果を出す計画

私はパフォーマンスを向上させるためにリファクタリングに取り組んでいるやや厄介なクエリを継承しました。

このプロセス中に、私が個人的な好みで行ったことの 1 つは、ANSI-99 結合構文のすべてを「内部結合」および「左外部結合」ステートメントからクエリの述語に変更することでした。2 つの非常に奇妙なことに気付きました。説明をいただければ幸いです。

1. 「INNER JOIN...」構文から結合を変更すると、説明計画が変更されました。ANSI 99 構文を使用すると、Oracle は結合される列に対して全表スキャンを実行しました。結合構文を変更した後、述語のプッシュが行われるようになりました。結合構文によって説明計画が変更されるのはなぜですか?
2. インライン ビューにプレディケートをプッシュすると、実際には、クエリが非常に大幅に遅くなります。(結合を変更する前に) 約 3 秒で実行されていたクエリ。現在、9秒かかります。正直なところ、私は説明計画を読むのはかなり初めてなので、クエリの再構築によって別の理由で速度が低下した可能性は十分にあります。しかし、最終的に私の質問は次のとおりです。

返信ありがとうございます。これが明確でない場合は申し訳ありません...