問題タブ [sql-execution-plan]

多くのテーブル (10-11) にまたがるかなり複雑なストアド プロシージャをデバッグしようとしています。ツリーの一部で、推定された行数が実際の行数と大幅に異なることがわかりました。実際には 55,000 行が返されるのに、最悪の場合、SQL サーバーは 1 行が返されると見積もっています!

これがなぜなのかを解明しようとしています - すべての統計は最新であり、いくつかのテーブルで FULLSCAN を使用して統計を更新しました。ユーザー定義関数やテーブル変数は使用していません。私が見る限り、SQL サーバーは返される行数を正確に見積もることができるはずですが、数万回の RDI ルックアップを実行する場合の計画を引き続き選択します (1 回だけ実行すると予想される場合)。または 2)。

推定行数が大幅にずれている理由を理解するにはどうすればよいですか?

更新：計画を見て、特に疑わしいと思われる1つのノードを見つけました-それは、次のプレデケートを使用したテーブルのテーブルスキャンです。

この述語はテーブル全体を返します (630 行 - テーブル スキャン自体がパフォーマンスの低下の原因ではありません) が、SQL サーバーの推定行数はわずか 37 です。SQL サーバーは、これを使用して RDI に対していくつかのネストされたループを実行し続けます。ルックアップ、インデックス スキャン、およびインデックス シーク。これが私の大規模な誤算の原因でしょうか? より賢明な行数を見積もるにはどうすればよいですか?

関数の結果に基づいてフィルタリングするストアドプロシージャがありDATEADDます-SQLサーバーはその関数の出力に基づいて統計を保存できないため、ユーザー定義関数の使用に似ていると理解しています。実行計画。

クエリは次のようになります。

（したがって、結果を事前に計算することはできませんDATEADD）

私が見ているのは、ひどいひどい実行プランです。これは、SQLサーバーがツリーの一部から返される行数を実際には約65,000であるのに、1と誤って推定しているためだと思います。ただし、データベースに異なる（必ずしも少ないわけではない）データが存在する場合、同じストアドプロシージャがほんのわずかな時間で実行されるのを見てきました。

私の質問は-このような場合、クエリオプティマイザーは関数の結果をどのように推定しますか？

更新：参考までに、私は、なぜあるときは良い実行計画を取得し、残りの時間は取得しないのかを理解することにもっと興味があります-私はこれをどのように修正するかについてすでにかなり良い考えを持っています長期的には。

SQL Server 2005 で次の手順を実行しようとしています。開発サーバーでこれを実行できましたが、ライブ サーバーでこれを使用しようとすると、「内部クエリ プロセッサ エラー: クエリ プロセッサができませんでした」というエラーが表示されます。クエリ プランを生成します。詳細については、カスタマー サポート サービスにお問い合わせください。」同じデータベースと同じフォーマットを使用しています。Web で検索すると、このエラーを回避するために SQL Server 2005 で使用されるいくつかの修正が示されていますが、私の DBA は、すべてのパッチがサーバーで更新されていることを確認しています。誰でも私にこれについての手がかりを与えることができますか？

クエリ:

クエリ アナライザを使用してテーブルのインデックスのパフォーマンスを比較するにはどうすればよいですか?

推定実行計画で同じクエリを 2 回 (1 回はインデックスを使用し、もう 1 回はインデックスを使用せずに) 実行し、生成されたテーブル スキャン/インデックス スキャンを適切に比較したいと考えています。

CREATE INDEX...、SELECT...、DROP INDEX...、SELECT を試しました。最初のクエリではインデックスを使用し、2 番目のクエリではインデックスを使用しないと予想されますが、両方の実行プランでインデックスが使用されます。

SQL2005/2008 のプラン キャッシュを検索して、実行プラン内にテーブル/インデックス スキャンがあるクエリまたはストアド プロシージャを特定するクエリを持っている人はいますか?

SQLサーバーは関数の実行プランをキャッシュしますか？

質問1：

クエリを実行すると、クエリを実行するたびに実行プランが変更されますか？

はいの場合、パフォーマンスに影響はありますか？

いいえの場合、テーブル内の何かを変更する場合、つまりインデックスを追加する場合、データベースは、実行プランを変更して実行を高速化するために使用できるものがあることをどのように認識しますか？

質問2：

ただし、結合クエリの実行中の一般的な実行順序は何ですか。特に、結合が多い場合（外部、内部、自然、外部が多い場合）はどうでしょうか。

特にクエリ内の同じリストへの複数アクセスの使用に関して、linq 式が何をするかを表示するアプリケーションを探しています。

さらに良いことに、このツールは linq クエリが適切かどうかを判断します。

私はテーブルを持っています。それを と呼びましょうHistory。主キー (別名クラスター化インデックス) は と呼ばれHIST_IDます。このテーブルには、開発 DB に約 2300 行あります。ここで、次の 2 つのクエリを検討してください。

クエリ 1:

クエリ 2:

唯一の違いはor @x is null、末尾にあります。ただし、最初のクエリはインデックス シークを実行し、2 番目のクエリはインデックス スキャンを実行します。何を与える？

先制応答 - いいえ、オプション (再コンパイル) は役に立ちません。

追加:推測ではなく、確固たる議論のある事実が欲しい. 私自身、これについて考えられる理由を十数個推測できます。しかし、ここで本当の問題は何ですか？

パラメーター化されたクエリからパラメーター化されていないクエリに変更したときの、SQL Server でのステートメントの推定クエリ プランの動作を理解するのに苦労しています。

次のクエリがあります。

このクエリは、Linq2SQL 式によって生成され、LINQPad から抽出されます。これにより、（私が知る限り）適切なクエリ プランが生成され、データベース上で約 10 秒で実行されます。ただし、パラメーターの 2 つの使用を正確な値に置き換えると、つまり、2 つの '= @p0' 部分を '= '1fc66e37-6eaf-4032-b374-e7b60fbd25ea' に置き換えます。クエリの実行時間が大幅に長くなりました (60 秒以上、まだ確認していません)。

一見無害に見える置換を実行すると、クエリ プランと実行の効率が大幅に低下するのはなぜでしょうか? 'DBCC FreeProcCache' でプロシージャ キャッシュをクリアして、不適切なプランをキャッシュしていないことを確認しましたが、動作は残ります。

私の本当の問題は、10 秒の実行時間 (少なくともしばらくの間) には耐えられますが、60 秒以上の実行時間には耐えられないことです。私のクエリは（上記のように）Linq2SQLによって生成されるため、データベースで次のように実行されます

これは同じように実行時間が長くなります（これは、パラメーター化されたクエリを使用しているように見えるため、二重に奇妙だと思います.

どのインデックスを作成するかなどについてアドバイスを求めているわけではありません。一見似ているように見える3つのクエリでクエリプランと実行がなぜそれほど異なるのかを理解しようとしているだけです。

編集:パラメータ化されていないクエリとパラメータ化されたクエリの実行計画、および別の GUID を使用してパラメータ化されたクエリの実行計画 ( Heinzが提案) をアップロードしました。

それが私を助けるのに役立つことを願っています:)