問題タブ [sql-execution-plan]

次のような2000互換モードで実行されているSQL2005サーバー上のデータでいっぱいのテーブルItemValueがあります（これはユーザー定義値テーブルです）。

FieldIDはItemFieldテーブルから取得されます。

2000モードではPIVOTを実行できないため、CASEとGROUP BYを使用して醜いクエリを作成し、一部のレガシーアプリでどのようにデータを取得するかを確認します。

このテーブルは、51番目のUDFまでの値を表示するためにのみ必要であることがわかります。クエリは次のとおりです。

FieldNumber制約が<=51の場合、実行計画は次のようになります。

SELECT <== Computer Scalar <== Stream Aggregate <== Sort (Cost: 70%) <== Hash Match <== (Clustered Index Seek && Table Scan)

そしてそれは速いです！約1秒で100,000以上のレコードを取り戻すことができます。これは、私たちのニーズに合っています。

However, if we had more UDFs and I change the constraint to anything above 66 (yes, I tested them one by one) or if I remove it completely, I lose the Sort in the Execution plan, and it gets replaced with a whole bunch of Parallelism blocks that gather, repartition, and distribute streams, and the entire thing is slow (30 seconds for even just 1 record).

FieldNumber has a clustered, unique index, and is part of composite primary key with the ID column (non-clustered index) in the ItemField table. The ItemValue table's ID and ItemNumber columns make a PK, and there is an extra non-clustered index on the ItemNumber column.

What is the reasoning behind this? Why does changing my simple integer constraint change the entire execution plan?

And if you're up to it... what would you do differently? There's a SQL upgrade planned for a couple months from now but I need to get this problem fixed before that.

いくつかのストアドプロシージャを調整しようとしていますが、インデックスについて質問があります。私はチューニングアドバイザーを使用しましたが、両方とも同じテーブルに対して2つのインデックスを推奨しました。問題は、1つのインデックスが1つの列用で、もう1つが複数の列用であり、最初から同じ列が含まれていることです。私の質問は、なぜ、そして何が違うのかということです。

ExplainPlanのコピーをOracleSQLDeveloper2.1.0.63からエクスポートしようとしています。

私が取得するのは、指定した名前のhtmlファイルと、同じディレクトリに新しく作成された「images」という名前のフォルダだけです。これは空です。

（cough）tabular（cough）HTML出力でスクイズを行ったところ、5ダースの画像が指定されていることがわかりましたが、CSS（スタイルはインラインで指定されておらず、CSSはインポートされていません）とJavascript（拡張/縮小領域）があると思います私も行方不明です。

最もユニークな画像の名前をグーグルで検索しようとしましたが、この問題に関する他のリソースが見つかりません。

これらの画像/CSS/ Javascriptをオンラインで入手できる場所はありますか、それともこれはバグであり、どこかに修正がありますか、それとも私はただの初心者ですか？

SQL Developerを使用しているマシンには完全な管理者権限があるため、特に自分のデスクトップ/ドキュメントでは、画像が保存されている別の場所がない限り、作成権限がないという問題にはなりません。検索しています今私のHDD、どこでもそれらを見つけることができるかどうかを確認するために...

予期しない結果をもたらす非常に単純なクエリがあります。どこでトラブルシューティングを行うべきかについてのヒントは大歓迎です。

簡素化されたクエリは次のとおりです。

これにより、クエリのコストは963になります。ただし、クエリを次のように変更すると:

同じデータが返されるはずですが、推定コストは17688まで跳ね上がります。ここでの問題はどこにある可能性が高いですか? ありがとう。

編集:クエリ プランによると、インデックスObsHead.Nameは範囲スキャンに使用され、ObsHead のテーブル アクセスのコストは 4 です。別のインデックスがObs.hdIdレンジ スキャンに使用されており、コストは 94 です。それは、テーブル間のネストされたループ結合です。 17K までジャンプします。

動的に作成されたLINQtoSQLクエリがあります。面白いことに、SQL Management Studioで実行すると、非常に高速になります。L2Sから実行すると、しばらくすると非常に遅くなります。

これは、クエリプラン/実行プランが原因である可能性があります。SQL Serverを再起動すると、L2Sクエリも非常に高速になります。

T-SQLを使用すると、WITHRECOMPILEを使用できます。しかし、L2Sでこれを行う方法は？

SQLServerのクエリプランをXMLから画像に変換できるようにしたいと思います。理想的にはベクター形式ですが、ビットマップでもかまいません。

これを行うためのオープンソースライブラリはありますか？または、SQL Server Management Studio DLLの1つを使用できますか？

ありがとう。

Microsoft SQL Server 2000 から 2008 にデータの一部を移行する作業を行っています。よくある問題などの中で、奇妙なことに出くわしました。以下にリンクされているのは、2000 年未満では非常に迅速に返される SQL クエリですが、2008 年未満では 20 分かかります。 WHERE 句にある次のステートメントにより、このステートメントに続くステップの実行計画が大幅に変更されます。

SQL ステートメントと実行計画は、以下にリンクされています。

同僚は、CASE ステートメントを使用して WHERE 句の一部を書き直すことができました。これは、オプティマイザーを「だまして」、より適切な実行計画を使用するように思われます。CASE ステートメントを含むバージョンも、リンクされたアーカイブに含まれています。

なぜこれが起こっているのか、また CASE ステートメントを使用するよりも洗練された解決策があるかどうかについて、誰かが説明を持っているかどうかを確認したいと思います。この特定の問題を回避することはできますが、残りの移行をできるだけ簡単に行うために、何が起こっているのかをより広く理解したいと考えています。

SQL ステートメントと XML 実行計画を含む zip ファイル

前もって感謝します！

2 つのデータセット間で大幅に異なる時間で返されるクエリがあります。1 つのセット (データベース A) の場合は数秒で返され、もう 1 つのセット (データベース B) は返されます。まだ十分に待っていませんが、10 分以上かかりました。MySQL 5.1.37 を実行している問題を再現できるように、これらのデータベースを両方ともローカル マシンにダンプしました。

興味深いことに、データベース B はデータベース A よりも小さいです。

問題を再現するクエリの簡素化されたバージョンは次のとおりです。

~2 秒で返される最初のデータベース (A) の EXPLAIN クエリ プランは次のとおりです。

>600 秒で返される 2 番目のデータベース (B) の EXPLAIN クエリ プランは次のとおりです。

データベース B が実行されているとき、MySQL 管理者を見ることができ、状態は無期限に「tmp テーブルにコピー中」のままです。データベース A にもこの状態がありますが、ほんの 1 秒程度です。

これらのデータベース間で、テーブル構造、インデックス、キーなどに違いはありません (show create tables を実行して、それらを比較しました)。

テーブルのサイズは次のとおりです。

注意すべき点:

• WHERE 句を削除すると、クエリは 1 秒未満で返されます。
• GROUP BY を削除すると、クエリが 1 秒未満で返されます。
• ev5、ev4、ev3 などを削除すると、削除するたびにクエリが高速になります。

AJ の回答後の更新: - データベース B (最大値 = 800002752) では、データベース A (最大値 = 3489) よりも ship_id のサイズが大幅に大きくなっています。これらが InnoDB テーブルであることを考えると、バッファを変更すると、このサイズのキーを処理するのに役立ちますか? これに対するさらなる更新：キーのサイズを縮小して再分析しましたが、パフォーマンスに変化はありません。

EVENT_TABLEの更新記述子:

両方のデータベースで同一であることに注意してください

そして、適切な測定のために、SHOW CREATE TABLE EVENT_TABLE:

データベース間でこれが異なる唯一の点は、自動インクリメント値です

誰でもこの問題を解決する方法を提案できますか? 私は何を逃したのですか？

マイケル・ホルツマンからの質問後 の更新 これは、彼の更新された STRAIGHT_JOIN クエリに基づく新しいクエリ プランです。データベース B には「Using temporary; Using filesort」がありますが、データベース A にはありません。これは、長いキーまたは同様のものが原因である可能性がありますか?

データベース A

データベースB

更新それは間違いなくデータ関連です。データベース A からデータをダンプし、次を使用してデータベース B にロードしました。

と

次に、データベース B のクエリがすばやく実行されます。データベースと同じ速さ A.データの何が問題なのかを診断する方法についてのアイデアはありますか??

UPDATE @newtover: データベース A から:

データベースBから（悪いもの）

そして、po_shipment の show create:

UPDATE @chris_I EVENT_TABLE 以外の他のすべての結合を削除してクエリを削除すると、同じパフォーマンスが得られます (つまり、くだらない)

UPDATE @Marcus Adams: 内部結合を削除して要求したプランのクエリ:

データベース A からのクエリ プラン (0.35 秒で応答)

データベース B からのクエリ プラン (お茶を淹れるのにかかる時間内に応答しない)

SQL Server 実行計画の物理演算子を理解しようとしています。このページは非常に役に立ちます:

http://technet.microsoft.com/en-us/library/ms191158.aspx

SSMS 2008 には、SSMS 2005 では表示されないいくつかの物理オペレーター プロパティが表示されEstimated Number of ExecutionsますNumber of Executions。しかし、これらは実際には何を意味し、リバインドやリワインドとどのように関連しているのでしょうか?

Estimated Number of ExecutionsXML に格納されていないように見えるため、特に興味深いものです。それで、それはどのように計算されますか？に等しいようEstimated Rebinds + Estimated Rewinds + 1.0です。しかし、もしそうなら、なぜ はNumber of Executionsと等しくないのActual Rebinds + Actual Rewinds + 1でしょうか?

ありがとう。

別の質問では、SQL Server のクエリ プラン キャッシュを制御する方法を調査しようとしていました。

https://stackoverflow.com/questions/2593749/is-there-an-equivalent-of-optionrecompile-or-with-recompile-for-an-entire-c

...そして、この記事でトレース フラグ 253 を見つけました。

http://www.sqlservercentral.com/Forums/Topic837613-146-1.aspx

記事は正しいです。DBCC TRACEON(253) を実行してからいくつかのクエリを実行すると、クエリ プラン キャッシュを手動でチェックして、プランが挿入されていないことがわかります。DBCC TRACEOFF(253) を実行すると、クエリ プランは通常どおりキャッシュされます。

だから私の質問は...このフラグは他に何をしますか? 公式ストーリーを知っている人はいますか？