- PR -

SQLの性能

«前のページへ 1|2|3|4|5
投稿者投稿内容
ハニワ祭り
大ベテラン
会議室デビュー日: 2005/11/15
投稿数: 115
投稿日時: 2006-07-08 13:57
そもそも遅い原因が推測ですから、絶対にそうとはいえませんが。
uk
ぬし
会議室デビュー日: 2003/05/20
投稿数: 1155
お住まい・勤務地: 東京都
投稿日時: 2006-07-10 12:04
引用:

ハニワ祭りさんの書き込み (2006-07-08 13:57) より:
そもそも遅い原因が推測ですから、絶対にそうとはいえませんが。

そうですね、だからこそコンパイル時間を確認してください、と書いたのですが。

チューニングでも何でもそうですが、問題の原因を「推測」して解決策を考えるのは、
それしか方法がないときだけです。この場合なら、コンパイルで時間がかかっているか
どうかは検証できるのですから、まずそれをすべきですね。
NEO
大ベテラン
会議室デビュー日: 2005/10/02
投稿数: 104
投稿日時: 2006-07-10 12:14
引用:

チューニングでも何でもそうですが、問題の原因を「推測」して解決策を考えるのは、
それしか方法がないときだけです。この場合なら、コンパイルで時間がかかっているか
どうかは検証できるのですから、まずそれをすべきですね。


コンパイルに時間がかかっているなら、一時テーブルを利用した方が速いかもということですか？
uk
ぬし
会議室デビュー日: 2003/05/20
投稿数: 1155
お住まい・勤務地: 東京都
投稿日時: 2006-07-10 14:13
いや、対策を考える前に原因を特定しろ、ということです。
原因がコンパイル時間にあるのなら、現状のSQL文ではダメだということなので、一時
テーブルの使用も含め、それに対応した対策を検討する、ということになります。
コンパイル時間が原因でないのなら、その対策自体が適当かどうかわかりません。
NEO
大ベテラン
会議室デビュー日: 2005/10/02
投稿数: 104
投稿日時: 2006-07-10 23:29
みなさん、今までいろいろとアドバイスありがとうございました。

問題のクエリのコンパイル時間を調べたところ、43秒くらいでした。
コンパイル時間がボトルネックだったようです。

紹介していただいた、一時テーブルを利用する方法で無事解決に至りました。
とても勉強になりました。
本当にありがとうございました。
«前のページへ 1|2|3|4|5

スキルアップ／キャリアアップ（JOB@IT）