ユーザ定義関数とストアドの速度面での違いが、今ひとつ理解出来ないのだが、結果として「ユーザー定義関数」をむやみに使うと速度が著しく低下することが有った。下記のサイトで説明されたているとおり使い方については要注意だと思った。下記のサイトから、改善のためのヒントが得られた。
http://comfair2.blog24.fc2.com/blog-date-200512.html
■ユーザー定義関数
最近、性能改善をやっていて身にしみて感じるのは「ユーザ定義関数」 のオーバーヘッドです。 多くの場合、性能改善の対象となるのはバッチ処理だと思いますが、 モノによってはコストの2/3を占めている場合があります。
「ユーザ定義関数」のコストはアナライザの実行プランに表示されな いため、「なぜ遅いんだろう?」ということになりがちです。 プロファイラでトレースを取ると、「え!なにこれ?」っていうほど表示されるのでなんとなくわかるのですが。
ユーザ定義関数は、簡単なサブルーチン的な処理(例えば端数処理とか) に使用すると開発効率は上がります。同じようなコードを埋め込まなくてもよいのでメンテナンス性もよいです。しかし、バッチの性能面から
見た場合は・・・。 「ユーザ定義関数」をどうしてもバッチで使用したい場合はselect句で。from句以降は使用しないこと。
■性能改善---時間計測時の注意
旧処理と新処理の処理時間比較計測・・・性能改善を行った場合は必ず行う作業です。一番大変なのはボトルネックを見つけるのはもちろんなのですが、テストデータを作成することでしょうか。
実際に蓄えられるデータ件数を見積もって、それと同等のデータを作成するわけです。
最近は個人データの流出事件等もあってユーザさんのデータを簡単にもらってくるわけにはいきませんから、なおさらです。
まあ、基本的なことなので、みなさんお分かりのこととは思いますが・・・。処理時間計測を行う場合は必ずリブートまたはサービスの停止/開始を行い、キャッシュをクリアしてから行いましょう。特に行数の多いSQLの場合、構文解析だけで数秒から数十秒かかる場合がありますから、へたをすると2倍くらい計測時間が違ってきます。
■ただいま性能改善中----(3)
性能改善、やっと終了しました。(というかさせました。) どうも、性能改善というものは凝りだしたらキリがないので困りものです。 今回、最後までボトルネックだったのは、巨大な実績テーブルの扱い方でした。from句のなかでテーブルをjoinする際、できるだけ小さな結果セットにしたほうが速いということは解っていたのですが、これを実現するのが・・・。
2分ほどかかっていた1つのSQL文が数秒で終わるようになりました。 やはり、性能改善は処理内容がある程度わかっていないと難しいものです。(時間もかかりますし。)
■パフォーマンス向上のためのヒント
SQLServerのパフォーマンスの向上に役立つ7つの方法には以下のようなものがあります。
1.プロファイラを使用する
2.パフォーマンスモニタを活用する
3.クエリアナライザのプラン表示機能を活用する
4.インデックスチューニングウィザードを使用する
5.ディスクの使用方法を考える
6.充分なメモリを確保する
7.SQLServerの自己管理機能に任せる(下手にさわらない)
このなかで面白いのは 7.でしょうか。
下手に設定するとSQLServerは機嫌をそこねたりします。