問題タブ [sql-execution-plan]

SQL ステートメントがどのように実行されているかを理解しようとするときは、実行計画を確認することをお勧めします。EXPLAIN PLAN を解釈する (意味を成す) には、どのようなプロセスを経る必要がありますか? 「おお、これは見事に動いているな」と目立たせるべきは何か？対「いや、そうじゃない」

テーブルTの列A、B、C、Dにインデックスがあります

WHERE 句で A、B、C を使用して T から取得するクエリがあります。

索引は使用されますか、それとも A、B、C のみを含む別の索引が必要ですか?

EXPLAIN PLAN ではコストが低いが、オートトレースでは一貫性のある取得回数が多いクエリが表示されることは何を示していますか? この場合、コストは数百で、CR は数百万でした。

今日、互換性レベル 80 (SQL2000) で実行されているデータベースで、Sql Server 2005 SP2 で実行されているストアド プロシージャに関する興味深いパフォーマンスの問題に遭遇しました。

proc は約 8 分間実行され、実行計画は、実際の行数が 1.339.241.423 のインデックスの使用を示しています。これは、テーブル自体の「実際の」実際の行数である 1.144.640 よりも約 1000 倍高い値です。推定行数による。したがって、クエリ プラン オプティマイザーによって与えられる実際の行数は、明らかに間違っています。

興味深いことに、proc 内の procs パラメーター値をローカル変数にコピーし、実際のクエリでローカル変数を使用すると、すべてが正常に機能します。proc は 18 秒実行され、実行プランは正しい実際の行数を示します。

編集: TrickyNixon によって示唆されているように、これはパラメーター スニッフィングの問題の兆候のようです。しかし実際には、どちらの場合もまったく同じ実行計画が得られます。同じインデックスが同じ順序で使用されています。私が見る唯一の違いは、パラメーター値を直接使用するときに PK_ED_Transitions インデックスの実際の行数を増やす方法です。

dbcc dbreindex と UPDATE STATISTICS を実行しましたが、成功していません。dbcc show_statistics も、インデックスの適切なデータを示しています。

proc は WITH RECOMPILE で作成されるため、新しい実行プランを実行するたびにコンパイルされます。

より具体的には、これは高速に実行されます。

そして、このバージョンは非常に遅く実行されますが、まったく同じ実行計画を生成します (使用されたインデックスの実際の行数が多すぎることを除けば):

何か案は？クエリプランを計算するときにSql Serverが実際の行数の値をどこから取得するかを知っている人はいますか?

更新: copat モードが 90 (Sql2005) に設定されている別のサーバーでクエリを試しました。同じ動作です。これはバグのように見えるので、ms サポート コールを開くと思います。

条件ステートメント（ IF ... ELSEなど）は、SQL Server（2005以降）のクエリ実行プランにどのように影響しますか？

条件文は実行計画の質を低下させる可能性がありますか？また、パフォーマンスを検討する際に注意する必要のある条件文の形式はありますか？

**追加するために編集**：

具体的には、キャッシュされたクエリ実行プランについて言及しています。たとえば、以下のインスタンスでクエリ実行プランをキャッシュする場合、条件付きの結果ごとに2つの実行プランがキャッシュされますか？

注：元の質問は意味がありませんが、関連するものを下までスキャンしてください。

次のような最適化したいクエリがあります。

どのキーが使用されているか知りたいのですが、説明するために渡すものは何でも、定数を入力したため、where句を最適化して何もできません(「不可能なWHEREに気づきました...」)。

• Explain で一定の​​最適化を行わないように mysql に指示する方法はありますか?
• 何か不足していますか？
• 必要な情報を取得するためのより良い方法はありますか?

編集：EXPLAIN定数値から生じるクエリプランを私に与えているようです。クエリはストアド プロシージャの一部であるため (また、spoc 内の IIRC クエリ プランは呼び出される前に生成されます)、値が定数ではないため、これは役に立ちません。私が望むのは、オプティマイザが実際の値がわからないときに生成するクエリ プランを調べることです。

私は何かを逃していますか？

Edit2: 他の場所で尋ねると、MySQL は、再利用するためにわざわざ行かない限り、常にクエリ プランを再生成するようです。ストアド プロシージャでも。このことから、私の質問は無意味であるように思われます。

しかし、それは私が本当に知りたかったことを意味のあるものにしません. 特定のクエリ内で定数である値を含むクエリを最適化するにはどうすればよいですか? -- たとえば、クライアント側のコードがwhere句に数値を含むクエリを生成しているとします。数値が不可能な where 句になる場合もあれば、そうでない場合もあります。Explain を使用して、クエリがどの程度最適化されているかを調べるにはどうすればよいですか?

私がすぐに見ている最善のアプローチはEXPLAIN、存在する/存在しないケースの完全なマトリックスに対して実行することです。手動で行うのは難しく、エラーが発生しやすいため、実際にはあまり良い解決策ではありません。

SQL Server 2005 でのクエリの実行プランの解釈に関する適切な記事、チュートリアル、または同様の参照はありますか?

Explain コマンドの出力で、「Seq Scan」と「Bitmap heap Scan」という 2 つの用語を見つけました。この 2 種類のスキャンの違いを教えてください。(私は PostgreSql を使用しています)

仕事で新しいクエリを開発しているときに、SQL Query Analyzer でそれを書き、プロファイリングしました。クエリは、テーブル スキャンがなくても非常に優れたパフォーマンスを発揮しましたが、ストアド プロシージャ内にカプセル化したときのパフォーマンスはひどいものでした。実行計画を見ると、SQL Server が TableB のインデックス シークの代わりにテーブル スキャンを使用する別の計画を選択したことがわかりました (テーブルと列の名前を少し難読化する必要がありましたが、クエリ ロジックはまったくわかりませんでした)。変更されました）。

ここにクエリがあります

クエリ「raw」を実行すると、次のトレース統計が得られます

そして、次のコマンドを使用してクエリをストアド プロシージャとして実行すると、

次のトレース統計を取得します

クエリを nvarchar に格納し、このように sp_executesql を使用して実行すると、同じ結果が得られます (sproc のように実行されます)。

ストアド プロシージャには、上記の select ステートメント以外は何も含まれていません。ステートメントがストアド プロシージャとして実行されるという理由だけで、SQL Server が下位の実行プランを選択する原因は何ですか?

現在、 SQL Server 2000で実行しています

次の 3 つの SQL ステートメントのパフォーマンスに違いはありますか?

それらはすべて機能し、同じ結果セットを返すはずです。しかし、内側の SELECT が tableB のすべてのフィールドを選択するのか、1 つのフィールドを選択するのか、それとも定数だけを選択するのかは問題でしょうか?

すべてのステートメントが同等に動作する場合のベスト プラクティスはありますか?