Q&A
回答ありがとうございます!
最適化されたクエリというのは、実行の都度最適化されるのでしょうか？
因みに、それぞれ何度か実行していますが、レスポンスに変わりがないので、キャッシュの影響ではないような気がしています。
また、参照テーブルに非クラスタ化インデックスを作成したら、大分レスポンスに差が無くなりました。
ストアド実行とクエリ実行では、インデックスの働き方が違うのかもしれません。
以下のクエリの実行について、レスポンスが異なる理由が知りたいです。
いずれも内容的には同じSELECT文です。
①アプリ(C#)からストアドプロシージャを実行する場合
②ManagementStudioでストアドプロシージャをEXECUTEで実行する場合
③ManagementStudioでストアドプロシージャの中身のクエリを実行する場合
上記について、①②は5分程度かかりましたが、③は２秒程度で結果が返ってきました。
SELECT結果は同じなのに、レスポンスに大きな開きがあるのは何故でしょうか？
「実行プラン」などのキーワードで調べましたが、よく分かりませんでした。
どなたか初心者でも分かるようにご説明頂けますでしょうか？
回答3件
0
②でもレスポンスが早いなら"SET ARITHABORT ON"を指定で行けそうですが状況が異なりそうですね。
ストアドのリコンパイルについては以下のサイトに詳しく書かれています。
http://engineermemo.wordpress.com/2013/08/02/%E3%82%B9%E3%83%88%E3%82%A2%E3%83%89%E3%83%97%E3%83%AD%E3%82%B7%E3%83%BC%E3%82%B8%E3%83%A3%E3%81%AE%E3%83%AA%E3%82%B3%E3%83%B3%E3%83%91%E3%82%A4%E3%83%AB%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/
投稿2014/08/29 01:16
総合スコア3541
0
ベストアンサー
ストアドプロシージャを利用することで最適化されたクエリーが実行されますが、これほど大きな開きが出るとは思えません。恐らく２の実行結果がキャッシュに乗り３の処理に反映されたのではないでしょうか。同じSQLで実行時間が全然違った事象は私も経験有ります。
気になってキャッシュに関して調べてみましたが、データキャッシュについて読み解けるサイトは見つけられませんでした。
投稿2014/08/28 13:42
総合スコア1339
0
最初に書かれている「実行プラン」を比較して、原因を探るような方法になるかと思います。
②と③の実行プランを見比べて、どのような差があるか？を確認します。
SQL-ManagementStuduioから実行するときに、
「実行プランを含める」を有効にします。
![実行プランを含める]WIDTH:600
結果ですが、速度を大きく下げる要因として、
「インデックス」以外を検索している量が多いなどがあるとおもいますので、
**「Table Scan」,「INdexScan」**などがあると、パフォーマンスは低下します。
不足しているインデックスも教えてくれるので、参考にします。
返答でインデックス追加で改善がみられた、とのことなので、
この手順で不足しているインデックス、特にどこで影響度が大きいかを確認してみてはいかがでしょう？
それぞれの処理で％表記で、どのくらい全体のなかの処理を占めているかもわかります。
両者の差が発生する理由は難しいですね・・・
統計情報などのクリアなどすれば、いっとき直るかもしれませんが、再発しそうなきもします。
あとは、今回あげられているほど大きな差があるとはおもえないですが、
暗黙の型変換などが多いと、パフォーマンスが落ちます。
要因はわかりませんが、①②と③で処理や、渡されている値の型などが違うなどがあるかもしれません。
そちらは、プロファイラーなどで実際に実行されているSQLを見てみるしかないと思います。
投稿2014/08/29 04:33
総合スコア100
回答ありがとうございます。
「実行プラン」ですが、以前に挑戦をしてみましたが、意味が分からず、挫折しました。
今回のことを機に、勉強したいと思います。
何かおススメの商材やサイトはご存知ですか？
また、プロファイラで実行されているストアドを引数ごとコピーし実行しているので、利用している値は①②と③で同じものです。
ご指摘を頂いた通り、実行プランの比較をするのが一番手っ取り早いのかもしれません。
更なる改善を目指してみます。
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2014/08/29 11:42