ストアドよりインデックスのほうが速いよ (185ﾚｽ)
上下前次1-新
21: 04/11/24 21:01 ID:??? AAS
>>20
実はデータリンクが IEEE-488。
22(1): a 04/11/27 09:59 ID:SLvZscV9(1) AAS
何回もＳＱＬを発行してない？最近みたプログラムで、カーソルのル
ープ使ってその中でさらに問い合わせを発行して、何万回もＳＱＬを
発行するようなプログラムを見た。
結局、テーブルを結合して一回で問い合わせが完了するようにＳＱＬ
を書き直したら、嘘みたいに早くなったよ。工夫してみれば？
23(2): 04/11/28 19:39 ID:??? AAS
22> ちみはまだ経験が足りん
24: 04/11/30 02:20 ID:??? AAS
>>23
なんで？1の書き込みには詳細が書いてないから、
22の意見が出てもおかしくないような気が。
25(1): 04/11/30 05:13 ID:??? AAS
結合するより、何回もSQL発行した場合も早いこともあるわけで 一概には言えないと？>>23
26: 04/11/30 12:15 ID:??? AAS
>>25
結合するだけで出来るような問い合わせが
自力ループより遅くなるとは考えにくいが。
-- 副問い合わせを含む問い合わせが
-- 自力ループより遅くなる事はある
27(1): 04/12/01 01:16 ID:??? AAS
今更ながら、1の書き込みを読み直してみるとｗ
問題点を通信のオーバーヘッドではないか？と考えているので
>>22さんの意見は、良いところをついているのではないかな。
昔の話だけど実際にそのようなケースを生産性・品質向上
取り組みの副作用として見たことがあるよ。
その時は共通チームが業務共通系の処理を共通関数として
提供してしまった?ため、それに関わるようなマスタテーブルは
そんな処理になってしまった。
最近はマシンも速いから一見遅くはないけど、負荷の高い処理って
なかなか問題が表面化しないで、地雷みたいに埋まってるんだよねぇ。。
28(1): 04/12/01 11:07 ID:??? AAS
>>27
問題とするところがまったく違うんじゃないか？
>>1 の上司が莫迦だって話だろう？ｽﾚﾀｲからしても。
29(1): 04/12/24 16:02 ID:tUfbN2jS(1) AAS
>>28
たしかに問題とする次元が違ってると思う。
｜非常に遅いでやんす。で、「バッチ更新はストアドで書き直したらどうですか？」って
｜上司に言ったわけです。勇気をふりしぼって。
インデックス…問い合わせ効率を向上させるためのもの（ツメ見出し）
ストアド…SQL文をプリコンパイル済みにして通常のSQLが問い合わせ前に行う
プリコンパイル作業等に掛かる時間的ロスを軽減する
でなかったか？
バッチ処理するのにインデックスあったら効率悪いので
インデックスをdrop
省8
30: 04/12/25 01:07 ID:otLeELiy(1) AAS
文面から察するに、SELECTして加工してUPDATEを繰り返してるんでしょ。
加工する内容次第だけど、インデックスよりはストアドじゃないかな。
でも、何もいじらずサーバのメモリ追加した方が楽だったり。
31: 04/12/25 01:16 ID:ROEABQwC(1/2) AAS
>>1はACCESSの話してるんだよ。
32: 04/12/25 09:37 ID:ZHJuMAXb(1) AAS
クエリ単体で50ms以下で遅いってことは、
無駄にSQL何回も発行してるのが原因なので
ストアドとかインデックスより、まず処理を見直すべき。
単純なＳＱＬをそのままストアド化しても意味無いよ。
あとインデックスはストアドに対しても有効だよ。
ストアドの実行計画みたことある？
33: 04/12/25 10:36 ID:??? AAS
（DB使うのにVB使うのやめれ）
＆
（今の時代アプリにオプソでも良いからDB必ず使え）
∴VB捨てれ
話はそれからだ
34: 04/12/25 11:59 ID:??? AAS
また、VB も使えない厨が来たのか ?
まず、「（DB使うのにVB使うのやめれ） 」の具体的理由を書いてみそ。
35: 04/12/25 12:05 ID:ROEABQwC(2/2) AAS
ストアドよりインデックスのほうがてっとり早いのは常識。
議論の余地なし。
36(2): 04/12/25 13:16 ID:??? AAS
VBアプリでメモリ多く使うと落ちる。
画面のコンポーネントべたべた貼る程度でｷｮﾄﾞる。
37(1): 04/12/25 13:26 ID:j8/J6yiR(1) AAS
まとめて大量のレコードを更新するような処理はテーブルロックがかけられるなら
いいのですが、通常運用中に実行しなければいけないときはどうしてますか？
where無しなどの大域処理をしてしまうと１命令を１トランザクションで実行しよう
とするから、ロックは広い範囲にかかりまくるし、オラクルだとロールバックセ
グメントに書き出しまくる。そのせいか処理が妙に重たい。
ストアドでカーソル使ってwhere current ofで処理しても、ループで内でupdateや
insert命令を実行してもロックやRBSがらみのリソースを消費してる感じです。
仕方がないのでクライアント側に一旦対象のレコードのキーをすべて書き出して、
それをキーにして数十件ずつコミットしながら更新かけてゆく方法をとったら
俄然処理が速くなりました。
省1
38(1): 04/12/25 15:33 ID:??? AAS
＞仕方がないのでクライアント側に一旦対象のレコードのキーをすべて書き出して、
これをDB内で済ませろ
39(1): 04/12/25 15:58 ID:??? AAS
>29
プリコンパイル(静的SQL)とストアドプロシジャは全く別のものだよ。
40(1): 04/12/25 16:23 ID:??? AAS
>>38
tempテーブルが使えるならそうするんだけど残念ながらOracle8なので使えません。
ログ運用してるんで通常テーブルをワークには使いたくないのです。
>>39
別の概念ではあるがプリコンパイルされないストアドって見たことはないですね。
上下前次1-新書関写板覧索設栞歴
あと 145 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.773s*