【SQLServer2008R2】ストアド実行とクエリ直接実行のレスポンスの違いについて
解決済
回答 3
投稿
- 評価
- クリップ 1
- VIEW 9,823
いずれも内容的には同じSELECT文です。
①アプリ(C#)からストアドプロシージャを実行する場合
②ManagementStudioでストアドプロシージャをEXECUTEで実行する場合
③ManagementStudioでストアドプロシージャの中身のクエリを実行する場合
上記について、①②は5分程度かかりましたが、③は２秒程度で結果が返ってきました。
SELECT結果は同じなのに、レスポンスに大きな開きがあるのは何故でしょうか？
「実行プラン」などのキーワードで調べましたが、よく分かりませんでした。
どなたか初心者でも分かるようにご説明頂けますでしょうか？
-
気になる質問をクリップする
クリップした質問は、後からいつでもマイページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
クリップを取り消します
-
良い質問の評価を上げる
以下のような質問は評価を上げましょう
- 質問内容が明確
- 自分も答えを知りたい
- 質問者以外のユーザにも役立つ
評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。
質問の評価を上げたことを取り消します
-
評価を下げられる数の上限に達しました
評価を下げることができません
- 1日5回まで評価を下げられます
- 1日に1ユーザに対して2回まで評価を下げられます
質問の評価を下げる
teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。
- プログラミングに関係のない質問
- やってほしいことだけを記載した丸投げの質問
- 問題・課題が含まれていない質問
- 意図的に内容が抹消された質問
- 広告と受け取られるような投稿
評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。
質問の評価を下げたことを取り消します
この機能は開放されていません
評価を下げる条件を満たしてません
質問の評価を下げる機能の利用条件
この機能を利用するためには、以下の事項を行う必要があります。
- 質問回答など一定の行動
-
メールアドレスの認証
メールアドレスの認証
-
質問評価に関するヘルプページの閲覧
質問評価に関するヘルプページの閲覧
checkベストアンサー
+2
気になってキャッシュに関して調べてみましたが、データキャッシュについて読み解けるサイトは見つけられませんでした。
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
+2
ストアドのリコンパイルについては以下のサイトに詳しく書かれています。
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/
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
+1
②と③の実行プランを見比べて、どのような差があるか？を確認します。
SQL-ManagementStuduioから実行するときに、
「実行プランを含める」を有効にします。
結果ですが、速度を大きく下げる要因として、
「インデックス」以外を検索している量が多いなどがあるとおもいますので、
「Table Scan」,「INdexScan」などがあると、パフォーマンスは低下します。
不足しているインデックスも教えてくれるので、参考にします。
返答でインデックス追加で改善がみられた、とのことなので、
この手順で不足しているインデックス、特にどこで影響度が大きいかを確認してみてはいかがでしょう？
それぞれの処理で％表記で、どのくらい全体のなかの処理を占めているかもわかります。
両者の差が発生する理由は難しいですね・・・
統計情報などのクリアなどすれば、いっとき直るかもしれませんが、再発しそうなきもします。
あとは、今回あげられているほど大きな差があるとはおもえないですが、
暗黙の型変換などが多いと、パフォーマンスが落ちます。
要因はわかりませんが、①②と③で処理や、渡されている値の型などが違うなどがあるかもしれません。
そちらは、プロファイラーなどで実際に実行されているSQLを見てみるしかないと思います。
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
2014/08/29 08:41
最適化されたクエリというのは、実行の都度最適化されるのでしょうか？
因みに、それぞれ何度か実行していますが、レスポンスに変わりがないので、キャッシュの影響ではないような気がしています。
また、参照テーブルに非クラスタ化インデックスを作成したら、大分レスポンスに差が無くなりました。
ストアド実行とクエリ実行では、インデックスの働き方が違うのかもしれません。
2014/08/29 09:08
実行順序を変えても変わらないのであれば、キャッシュでは有りませんね。失礼いたしました。
2014/08/29 20:31
色々と勉強になりました。
回答も早くいただき、どうもありがとうございました。