ストアドよりインデックスのほうが速いよ

1 ：04/09/02 〜 最終レス ：2013/04/29

なんかね、データベースからデータを取得して VB で簡単な加工して、
書き戻すっていう更新処理があったのよ。当然、C/S 間のピンポン多発で
非常に遅いでやんす。で、「バッチ更新はストアドで書き直したらどうですか？」って
上司に言ったわけです。勇気をふりしぼって。
そしたら「ストアドよりインデックスのほうが速いよ」って。(ﾟДﾟ)ﾊｧ?
「クエリ単体の実行時間は 50ms 以下なので遅いのは呼び出しのオーバーヘッドが…」
「データベースが遅いのはね。インデックスなんだよ。たとえば、君の言う
50ms がインデックスを工夫することで 20ms になったら倍以上に速くなるんだよ。」
「いや、50ms が 20ms になっても体感できないと思うんですが…」
「そんなことやってみなくちゃ分からないだろ！！！ やりもしないで何を
　言ってるんだよ。インデックスは奥が深いんだよ」
「いまでも主キー指定での取得になっていて…」
「もういいよ。オレがインデックス張ってやるから、まあ見てから言えよ。な？」

2 ：

もっと分かりやすく文章かけよ
何がいいたいのかﾜｶﾝﾈ

3 ：

スレ建てないで雑談スレに書けよ

4 ：

>>1 削除以来出しとけよ。

5 ：

なんだか言っていることが面白いよね。
本当雑談だよ。
入社１年目の初心者でしょ。
そのあとの話の展開がどうなったのか教えてちょ。

6 ：

>>1にはそのピンポン多発で非常に遅いアプリをどうにかできるだけの
VBやネットワーク、OS辺りの幅広い知識を身につける必要があるという事を
認識してほしい。

7 ：

>>1
逆にストアドプロシージャでは解決する見込みはないと思うけど、解決すると
判断したその根拠は何だろう。
詳細が分からないから断言は難しいけど、やっぱりインデックスが重要だと
思うなぁ。経験的に。

8 ：

…まあ見てから言えよ。な？
>>1の上司は熊先生に似たナイスガイ(ｳﾗﾔﾏｽｨ

9 ：

こんな感じか？ たとえば、半角全角混在の文字項目を全角に統一する。
(1) レコードセットを取得する。
(2) VBの関数を使って、1レコードを全角に変換して、1レコード分の update 発行。
このようなユーザーの意思を必要としない処理はストアドにして一括更新したほうがいいね。
(2) を何万回も繰り返すのはアホ。

10 ：

>>1
そろそろ結果を報告しなよ

11 ：

>>7
プロシジャで処理することと
インデックスを張ることは
背反しません。
>経験的に。
無知なまま経験を積んでも実になりませんよ。

12 ：

>1
ミドルウェアの記述がないので、Java環境での話をすると
以前調べた時、NWとミドルを含めたオーバーヘッドは1,2msだった。
数万件単位で大量件数を処理するならSP化は有効だけど
オンライン系で遅いなら他にボトルネックがあると思われる。
もしかして、毎回コネクション張りにいっているという
オチじゃないだろうな・・
ちなみに、更新系はC/S環境でもSPに匹敵する性能がでるよ。
参照系は、SPには勝てんが。。

13 ：

質問：
３層c/sでアプリサーバーとDBサーバーが同じノード上にある場合はストアド使わなくても
パフォーマンス出るんでしょうか？

14 ：

http://jbbs.livedoor.jp/sports/352/

15 ：

>>13
ストアドの方が僅かにでも速くなることが多い

16 ：

>>2-15
まぁそんなにムキるな。どーせ釣りだろ(ｗ

17 ：

どうしようって言うくらい馬鹿ばかりだなこのスレ。
>>5-7あたりがネタじゃなくて真面目に言ってるとしたら、日本のIT技術者が
素人ばかりというのもあながち間違ってない。

18 ：

>>1の文章が理解できません・・・
どれが1の発言で、どれが上司の発言なんでしょうか？

19 ：

>17
たぶん正解だな。
ただ、バカだと思うなら、貴方なりの回答を
聞かせて欲しいものだ。

20 ：

>12
＞もしかして、毎回コネクション張りにいっているという
＞オチじゃないだろうな・・
そんな気がす・・・

21 ：

>>20
実はデータリンクが IEEE-488。

22 ：

何回もＳＱＬを発行してない？最近みたプログラムで、カーソルのル
ープ使ってその中でさらに問い合わせを発行して、何万回もＳＱＬを
発行するようなプログラムを見た。
結局、テーブルを結合して一回で問い合わせが完了するようにＳＱＬ
を書き直したら、嘘みたいに早くなったよ。工夫してみれば？

23 ：

22> ちみはまだ経験が足りん

24 ：

>>23
なんで？1の書き込みには詳細が書いてないから、
22の意見が出てもおかしくないような気が。

25 ：

結合するより、何回もSQL発行した場合も早いこともあるわけで 一概には言えないと？>>23

26 ：

>>25
結合するだけで出来るような問い合わせが
自力ループより遅くなるとは考えにくいが。
-- 副問い合わせを含む問い合わせが
-- 自力ループより遅くなる事はある

27 ：

今更ながら、1の書き込みを読み直してみるとｗ
問題点を通信のオーバーヘッドではないか？と考えているので
>>22さんの意見は、良いところをついているのではないかな。
昔の話だけど実際にそのようなケースを生産性・品質向上
取り組みの副作用として見たことがあるよ。
その時は共通チームが業務共通系の処理を共通関数として
提供してしまった?ため、それに関わるようなマスタテーブルは
そんな処理になってしまった。
最近はマシンも速いから一見遅くはないけど、負荷の高い処理って
なかなか問題が表面化しないで、地雷みたいに埋まってるんだよねぇ。。

28 ：

>>27
問題とするところがまったく違うんじゃないか？
>>1 の上司が莫迦だって話だろう？ｽﾚﾀｲからしても。

29 ：

>>28
たしかに問題とする次元が違ってると思う。
　｜非常に遅いでやんす。で、「バッチ更新はストアドで書き直したらどうですか？」って
　｜上司に言ったわけです。勇気をふりしぼって。
インデックス…問い合わせ効率を向上させるためのもの（ツメ見出し）
ストアド…SQL文をプリコンパイル済みにして通常のSQLが問い合わせ前に行う
　プリコンパイル作業等に掛かる時間的ロスを軽減する
でなかったか？

バッチ処理するのにインデックスあったら効率悪いので
インデックスをdrop
↓
バッチ
↓
インデックスを(再びCreate)
↓
（シェアードテーブル化できないならSELECT文でキャッシュに）
だろう…

もっと詳しい人どうぞ。（ｗ

30 ：

文面から察するに、SELECTして加工してUPDATEを繰り返してるんでしょ。
加工する内容次第だけど、インデックスよりはストアドじゃないかな。
でも、何もいじらずサーバのメモリ追加した方が楽だったり。

31 ：

>>1はACCESSの話してるんだよ。

32 ：

クエリ単体で50ms以下で遅いってことは、
無駄にSQL何回も発行してるのが原因なので
ストアドとかインデックスより、まず処理を見直すべき。
単純なＳＱＬをそのままストアド化しても意味無いよ。
あとインデックスはストアドに対しても有効だよ。
ストアドの実行計画みたことある？

33 ：

（DB使うのにVB使うのやめれ）
＆
（今の時代アプリにオプソでも良いからDB必ず使え）
∴VB捨てれ
話はそれからだ

34 ：

また、VB も使えない厨が来たのか ?
まず、「（DB使うのにVB使うのやめれ） 」の具体的理由を書いてみそ。

35 ：

ストアドよりインデックスのほうがてっとり早いのは常識。
議論の余地なし。

36 ：

VBアプリでメモリ多く使うと落ちる。
画面のコンポーネントべたべた貼る程度でｷｮﾄﾞる。

37 ：

まとめて大量のレコードを更新するような処理はテーブルロックがかけられるなら
いいのですが、通常運用中に実行しなければいけないときはどうしてますか？
where無しなどの大域処理をしてしまうと１命令を１トランザクションで実行しよう
とするから、ロックは広い範囲にかかりまくるし、オラクルだとロールバックセ
グメントに書き出しまくる。そのせいか処理が妙に重たい。
ストアドでカーソル使ってwhere current ofで処理しても、ループで内でupdateや
insert命令を実行してもロックやRBSがらみのリソースを消費してる感じです。
仕方がないのでクライアント側に一旦対象のレコードのキーをすべて書き出して、
それをキーにして数十件ずつコミットしながら更新かけてゆく方法をとったら
俄然処理が速くなりました。
こういうケースでは一般的にはどうするのがいいのでしょうか？

38 ：

＞仕方がないのでクライアント側に一旦対象のレコードのキーをすべて書き出して、
これをDB内で済ませろ

39 ：

>29
プリコンパイル(静的SQL)とストアドプロシジャは全く別のものだよ。

40 ：

>>38
tempテーブルが使えるならそうするんだけど残念ながらOracle8なので使えません。
ログ運用してるんで通常テーブルをワークには使いたくないのです。
>>39
別の概念ではあるがプリコンパイルされないストアドって見たことはないですね。

41 ：

>>40
俺は見たことあるぞ？

42 ：

コンパイルといっても構文解析フェーズを済ましておく程度だけどね。
最初の実行時にコンパイルするタイプのを見かけますな。
>>37 はストアドが必ずしも役に立つわけでない例を挙げてみてるんだろうな。
OracleのPL/SQLだと普通の手続き型言語に似てるからとっつきは良いけど
使い方は要注意だ。非効率な変な書き方もできてしまうからな。

43 ：

>>36
OS かお前のマシンがしょぼいんじゃねーか ?
あるいは、バグバグしてるコンポーネント使いまくりとかな。

44 ：

http://plaza.rakuten.co.jp/batrowa/
ここに行ってゲームのことを一から学ぶ<丶｀Д´>ﾆﾀﾞｰ

45 ：

>>36
自分の技術の無さをVBのせいにするな

46 ：

そもそもバッチ更新なのにコンポーネントは全く関係なし。
アプリに負担をかけることすら間違い。
それとクライアントに一端処理を移すとのことだけれども
ストアドやインデックス云々より、DBの構造を見直した
方が早いよ。

47 ：

ストアドよりインデックスのほうがてっとり早いのは常識。
議論の余地なし。

48 ：

ボトルネックを調べてみるのにまず手っ取り早い索引から調べるというのは
同意だが、実際の対策としてストアドとインデックスを比べるのは意味はない。
まったく別物だからなぁ。
要領を得ないことをいう部下を信用しないのは上司の基本だと思うな（笑）

49 ：

>>1を叩くのは2ﾁｬﾝﾈﾗの基本だと思うな（笑） ←笑って付けるだけでキモヲタ風味になる。

50 ：

つーか　どんな業務なのかを教えろよまず。

51 ：

>>46-47
ｵﾏｲﾗ、論点がずれてる。
>>48
正解

>>1の場合であればストアドのようなサーバサイドの処理にした方がパフォーマンスが上がると思う。
さらに、可能であれば、『UPDATE ･･･ SELECT』 文にした方がベターだな

52 ：

>>51
論点がずれてる。
上司が言ったのは、すばやく目標を達成するにはって話だ。
よって、インデックスで良いんだよ。
それを>>1が高速化技法の話に摩り替えた。
よく読め。

53 ：

>>52
>よく読め。
>>1
>「いまでも主キー指定での取得になっていて…」
莫迦麦価

54 ：

>>53
お前こそよく読め。
>「いまでも主キー指定での取得になっていて…」
何で主キー指定して取得してるのにストアドなんだよ？
意味無いだろ。
その点を上司がたしなめたんだろ。
きちんとインデックス張ってまともなクエリ書けと言う意味だろ。
お前はストアドなどとの給う前にやることがあるだろ？と言われたわけだ。

55 ：

なんつーか、やれやれですな。
>>54
>何で主キー指定して取得してるのにストアドなんだよ？
>意味無いだろ。
ストアドプロシジャの利点は、RDB サーバの _プロセス内で
処理が閉じている_ 点にある。その為、>>1 の指摘する
>C/S 間のピンポン多発で非常に遅いでやんす。
が解消される事が期待できる。
一方、主キーには _既にインデックスは作成されている為_、
二重にインデックスを張る行為には _全く意味がない_。

56 ：

>>55
同意。やれやれだよ。
>>54あたり本気なのかネタなのかすら判別がつかん。
何でこんな基礎的な話で議論になるのか…。

57 ：

主キー指定して取得するからピンポンが発生するんだろ。
なぜ、主キー指定して取得してるのに、ピンポンを発生させているのか考えれば、
わかる話だろう。
まともなSQL書けばすむ話だ。
ストアド以前の話だな。
よってインデックスが正しい。

58 ：

>>57
(　ﾟДﾟ)ﾎﾟｶｰﾝ
考えれば分かる話だろう。
じゃなくて、そこんとこ詳細に説明してみ。
どんな珍説なのか是非聞いてみたい。

59 ：

>>58
わからないなら黙ってろ。

60 ：

>>59
負け犬乙

61 ：

「>>57 の考え、休むに似たり」
>よってインデックスが正しい。
>>55
>二重にインデックスを張る行為には _全く意味がない_。

62 ：

>>61
m9（＾Д＾）ﾌﾟｷﾞｬｰ ぜんぜん意味わかってねー。

63 ：

＞いまでも主キー指定での取得になっていて…
これと似た台詞を聞いたことがあるけど、念のため調べてみたら
primary key (項目A, 項目B)の構成のテーブルで
項目Bだけで検索してたというのがあったよ。
大昔のRDBのなかには
a) where 項目A = ? and 項目B = ?
b) where 項目B = ? and 項目A = ?
で索引を使ったり使わなかったりしたのもあったけど最近のは大丈夫ですよね？

64 ：

>>57
想像するに…
・一行ずつ取得ではなく、複数行持ってきてUPDATEはループで回せ。
・UPDATE一発でやれ
のどちらかを言いたいのだと思うけど、それじゃ出来ない処理なんて
いくらでもある。そう言うときの為にストアドがある。
そもそも
「ストアドが存在するDBMSにもかかわらずクライアントでバッチ更新」
なんて仕様が出てくる時点で間違い。
>>63
> 最近のは大丈夫ですよね？
そうでもないよ。

65 ：

>>64
物事には順序がある。
一行ずつ取得してる新人に、いきなりストアドでやれとは言わない。
ストアドなどという前にやることがあるだろう。

66 ：

>>65
VBでバッチ処理が書けてストアドだと書けないなんて事があるか
どう考えてもストアドの方が簡単だろう。
単なる怠慢。

67 ：

ストアドでバッチ処理を書き直したまではいいのだけれど、
数件おきにコミットさせるとカーソルがクローズしてエラーになってしまう。
１件分の処理の間に子レコードの処理も入るのでトランザクションは使いた
いのだが全部処理するには総数が大きい。さてどうするべ、週末なのに・・・

68 ：

やかん

69 ：

>>67
Oracle で、FOR UPDATE 付きの問い合わせをしてるなら
それは仕様。ROWID 使え。
Oracle じゃないなら知らん。
つか、ｽﾚ違い。

70 ：

>>67
コミット後にカーソルをオープンしたままにする方法はないの?
大抵のDBMSならできるはずだけど。

71 ：

そこでインデックスですよ。

72 ：

>>57でキーボードに茶を吹いたよ。 どうしてくれる。
>>64はきっと釈迦のような慈悲の心を持っているんだろうな。

73 ：

確かに>>57って笑えるｗ

74 ：

>>70
DB2とかのやり方をまねしちゃだめ。
カーソルループ中にCOMMITする発想はあんましよくない。
途中でこけたら元に戻せなくなる。
そういう場合はロールバックセグメントを大きくとっておくのがOracleのやりかた。

75 ：

えせOracleの香りがぷんぷんする

76 ：

>>74
最後の一行は要らなかったな

77 ：

>>74
そうか？ケースバイケースだろ。
カーソルループの中で一部のデータのみコミットされると整合性がとれ
なくなるなケースはおっしゃる通りだが。
カーソルループの中で一部のデータのみコミットされても整合性がとれ
るケースだってないか。
その場合は、カーソルループの中でコミットしたほうがロックの期間
が短くなるし、いいと思うけど。
ロックの期間を短くしたほうがいいっていうのは、どんなDBでも同じ
じゃねーか。

78 ：

>>77
カーソルループでの更新が途中でこけると、どこまでやったかがわかんないから最初からやり直すことになると思うけど。
このとき、途中までCOMMITしてたらそこまでの更新をもう1回やることになる。
それでも整合性がとれるようなケースってあんましなさそうな気がするけど...

79 ：

>>78
その通り。
>>77のケースはやろうとすれば出来るだろうけど、
管理が非常に難しくなるし、
どこまでコミットしたかの情報も一々記録しないといけないからパフォーマンスも悪くなる。

80 ：

そのあたり、セーブポイントでどうにかできないのでしょうか。

81 ：

そもそもセーブポイントって、どういうものか理解しているのか？

82 ：

>>78,79
カーソルループの中で整合性が取れるケースって、珍しくはないよ。
いくつか思いつくけどね。
例えば、受注テーブルを基に、物流システムへ渡す出荷指示データ
を作成するバッチ処理とか。
受注テーブルの出荷指示フラグと出荷日を基にカーソルループでまわす
場合。で、ループの中では、受注テーブルの出荷指示フラグを更新し、在庫
テーブル更新、出荷指示テーブル作成とかやってる場合、処理する受注伝票
単位で整合性が取れてれば問題ないというケース。
>管理が非常に難しくなるし、
どこまでコミットしたかの情報も一々記録しないといけないからパフォーマンスも悪くなる。
正直、意味が良くわからん。多分、管理が非常にむずかしくなるってのは、
どこまでコミットしたかを把握したいという意味なんだろうけど。
すでにコミットしたデータは、整合性が取れてるわけだから、基本的には気に
する必要はない。プログラムの不具合で、コミットしたデータの信頼性が損なわれている
場合でも、テーブルに更新時のタイムスタンプと最終更新PGMのIDでも持たせて
おけば、調査できるだろ。
基本的にはバグなんだから、それよりロックの期間が長くなるというデメリット
のほうが俺はいやだね。

83 ：

>>82
彼らの言っているのは
> ループの中では、受注テーブルの出荷指示フラグを更新し、在庫
> テーブル更新、出荷指示テーブル作成とかやってる場合
この「ループの中」の途中でコミットしてしまうと言うケースを想定して
話をしているんだよ。
「カーソルループ」と言う言葉に捕らわれすぎで話の本質が分かってない。

84 ：

>>83
そうなのか？だとすると確かにレアケースだが。
67の質問ってそういう意味じゃねーと思うがな。実際、DB2,MSSQL,
Oracleもデフォルトじゃコミットしたら、カーソルクローズしちゃう
しな。(SQL92の仕様だからだろうけど。）
69の回答も俺とおんなじ理解だろ。
話の本質が分かってないのは、お前のほうじゃねーかって気がするがな。

85 ：

>>84
67に対しては69でFA出てる。
そこから先の話はトランザクション内でのコミットの是非についてだろ。

86 ：

訂正
67に対しては70でFA出てる

87 ：

>>85
>そこから先の話はトランザクション内でのコミットの是非についてだろ。
そんなのまずいに決まってんじゃん。トランザクションの1つの要件は、
整合性を確保できる最小単位であることだ。（原子性、一貫性）
俺が77で言っているのは、カーソルループ1回単位が１トランザクション
の場合と、カーソルループ全体が１トランザクションの場合の話。
>>67に対しては70でFA出てる
やっぱり話の本質が分かってないのは、お前のほうだと思うがな。俺は、
70に対する返答(74)に対して、77で返答してんだから。
どこから、トランザクション内でのコミットの是非についてになったん
だ。

88 ：

>>87
言ってる意味がさっぱりわからん
とりあえず落ち着け

89 ：

>>88
二段落目読んでも解らないとなるとヤバイ。

90 ：

そもそも同列に語ることがおかしいってスレでいいんだよな。
・ストアド化による性能向上
ミドルウェア及び通信等のコスト減を目的
・インデックスをきちんとすること
データに対するアクセス経路の最適化を目的

91 ：

>>90
>>67 以降、違う話に花が咲いています。

92 ：

>>90
>>91の言うように、話題が変わってます。
カーソルループで大量更新をする場合の話。
>>87,88
想定している状況がそれぞれ違ってるみたいだから
ちょっとこじれかけてるけど、めずらしくまともな議論
に育ちそうだからマターリいこーぜー。

93 ：

すごい遅レスだが。
>そんなのまずいに決まってんじゃん。トランザクションの1つの要件は、
>整合性を確保できる最小単位であることだ。（原子性、一貫性）
これは、トランザクションは整合性を確保する最小単位だから、
トランザクション内部でのコミットは有り得ないということが
言いたかった。

94 ：

OracleのSPはネーティブコードではなくインタプリタのようです、
ＤＢの問い合わせではなくロジックをしこたま実行するプログラムを作ったの
ですが予想の百倍ぐらい時間がかかりました。
SPそれ自身の実行速度はVBとたいして変わらない印象です、
サーバに中途半端なCPUを使うとPCでVBのほうが早い可能性も
ありです。

95 ：

>>94
たいていの処理系ではStored ProcedureはP-Codeのような中間言語方式だから
Oracleもそうじゃないかな。一般的にサーバーサイドでCPUを多く使う処理は
避けたほうがいいから問題ないように思う。複雑な処理をしたいならOracle内臓の
JServer VMでJava stored procedureを使うという手もある。こちらはJITでコンパ
イルされるから２回目以降の処理は速い。

96 ：

>>94
>OracleのSPはネーティブコードではなくインタプリタのようです
んな事ぁちょっと考えれば解（ｒｙ

97 ：

>>94-96
PL/SQLはネイティブコンパイルもできる

98 ：

>>97
そういえばそんなのがありましたね。Cコンパイラが別に必要だったり、
設定がめんどかったり、SQLなどのDBアクセス部分には効果がなかったり
で結局使いませんでした。
＞ＤＢの問い合わせではなくロジックをしこたま実行するプログラムを作ったの
こういうのには効果がありそうです。

99 ：

ここが一番ヘビーユーザーが多いみたいだね
教えて欲しいのだが、行レベルロックに対応しているDBはオラクル
以外にありますか？

100 ：

>>99
SQLServer

101 ：

>>99
Access2000/2003

102 ：

>>100
いやMSSQLは、テーブルごとロックする
読み取り以外はロック待ち状態になった気がした

103 ：

>>102
はぁ？
SQLServer2000であれば行単位のロックが可能だよ。
あまりにも膨大になってくると、ロックエスカレーションを引き起こし表単位のロックになるがな。

104 ：

>103
あれって、インデックスが無いと
ページになるんじゃなかったけ？
勘違いかな。

105 ：

>>104
「テーブルスキャン」と混同してない?
SQLServerは7.0から行ロックをサポートしてるし、Sybaseは11.9.xから。
DB2は知らんけど、今時行ロックサポートしてない商用RDBMSなんて相手に
されないと思うけど。

106 ：

>>99
おまいはここが質問ｽﾚかどうかも解らんのか？

107 ：

>1 を読む限りここは愚痴スレだね。

108 ：

10年ぐらい前なんでよく憶えてないが、DB2も行ロックするよ

109 ：

運用担当が行ロックをありがたがるのは理解できるのだが、
開発担当が行ロックじゃなきゃ使えないとか言ってるのを聞くと
それは技術力がないという以前の単なるへたれなだけのような気がする。

110 ：

>>109
はぁ？

111 ：

>ストアドよりインデックスのほうが速いよ (＜−−スレタイ)
それぞれ、どのようにした速度が改善されるのかを考えたほうがいい
ストアドによる処理速度の向上は以下の２点による。
１．プログラムがサーバーにあるためサーバークライアント間の
　　回線経由のデータ転送をなくすことによる速度アップである
２．SQLを中間言語に落とすことにより、インタープリタの必要がない
インデックスによる速度改善とは以下
３．ディスクアクセスを少なくする。
ストアドを使うときの注意事項
４．ストアドはＬＡＮ環境だと１．の速度アップは期待できない。低速の
　　ネットワークならば期待できる。
５．ストアドのプログラムの管理が面倒。デバックしにくいＤＢもある。
結論を言うと、
６．インデックスによる速度アップはすべきである。
　　（というか、これをしないと普通は、実運用に耐えられない）
７．ストアドによる速度アップはＬＡＮ環境でのＣ／Ｓの場合は
　　期待できない。低速回線経由のＣ／Ｓならば期待できる。
８．ロジックを共有するという目的ならばストアドの使用は可。
以上かな。

112 ：

> 111
あんたが正解。
クエリー投げてカーソル範囲を確定するのに
一番影響するのがインデックスだし、
インデックスをつけても、変わらないのがC/S間の
データ転送速度。（FETCHね）
ストアドなら、ネットワークインフラの性能が
左右するが、クライアントからのちまちました
カーソルFETCHかますより、全レコードを配列変数などで
アウトパラメタとして一括送信したほうが早い場合も
ある。
全て条件付きのケースバイケースだけど、
「クエリを実行してカーソルを確定する」部分と
「カーソルからレコードを取得する」部分の違いは
ちゃんと理解したほうがいいですね。
FETCHしたレコードが大して多くないのに、処理が遅いとかって、
大体クエリの効率が悪く、カーソル処理の場合FETCH − LOOPではなく
その前のクエリ実行が遅かったりする。
そんなときは、いくらストアドにしてもだめ。
SELECT文の実行計画を調べて、その対処としてインデックスを
付与することが明らかであれば、そうすべし。

113 ：

> ストアドによる速度アップはＬＡＮ環境での C/S の場合は期待できない。
これには反論あり。100Mbps の LAN であってもサーバーカーソルを使うと
著しいパフォーマンス低下をもたらす。参照系だけでファイアーホースを
使うならともかく、サーバーカーソルを使ってフェッチ&アップデートを
繰り返すなんて LAN でもやるべきではない。
>>1 はフェッチ&アップデートの多発で速度低下していると言っているのだろう。
その考えは結構正しい。LAN であってもユーザーの判断・操作を
必要としない一括更新はストアドにすべし。クライアントプロセスで
更新する必要性がなかろう。

114 ：

ここは「頭の悪そうな発言をする」スレですか？

115 ：

>>111
ストアドの利点はもう１つあって、それは静的ＳＱＬ構文であること。
既にコンパイル済みなので、ＳＱＬ文の構文解析の手間が無いので高速。

あと高速化とは関係無いけど、バグが発生した場合はＤＢサーバに対して修正するだけで良い。
Ｃ／Ｓシステムほど、その効果が高い。

116 ：

>>114
愚痴ｽﾚだって事に気付かない莫迦がｽﾚ伸ばしてたからね。
で、前の方の書き込み見ずに蒸し返す莫迦がageやがった、と。

117 ：

>>114
いいえ、的外れなことをそれっぽく言ってみようとするスレです

118 ：

>>114, 116, 117
君たちの見解を知りたいものだ

119 ：

クソスレの有効利用でいいことじゃないか。何を粘着してるんだか。

120 ：

> 113
DBサーバ上のローカルアクセスならLAN性能は関係ないぞ。
サーバマシン単体の性能なら話はわかるが。

121 ：

>>120
いや同一ホスト内であってもサーバーカーソルを別プロセスから
動かすってのは、かなりの高コスト処理なのよ。
ADO なんかで MoveNext とかするでしょ。サーバーカーソルの場合
そのたびにサーバーカーソルを動かすためのストアドとかが裏で呼ばれるわけ。

122 ：

だから、FETCHもサーバ（プロセス）でやって、データを一括で返せば？
SQL Server のストアドは詳しくないが、アウトパラメタで配列
返すことはできたっけ？

123 ：

>>122
クライアントカーソルの事だな。

124 ：

>>122
SQL Serverの場合は１クエリーで処理できないような問い合わせは
Temptテーブルを仲介させると効率よく処理できる。
table型はストアドの外では使えなかったと思う。

125 ：

似たような速度の話を一つ。
３０００件（５フィールド）のデータがあるとして、
１．ストアド内でカーソルで回して使用
２．最初に配列に取り込みカウンタで回して使用
上の数字は、適当なものだけど、こゆ場合は、どっちが速いの？
カーソルって１レコード分のデータのみメモリにあるのかな？
ＤＢアクセスしてるとしたら、２．のが速そうなんだけど。
だれか分かる人〜

126 ：

配列にいれると２度手間だからどう考えても遅いよ。
データベースの種類にもよるけど、メモリにあるのはキャッシュされた複数レコード。
SQLをコンパイルしたコードとインデックス位置を保持してるのがカーソル。
読み込みはキャッシュか物理記憶からその情報を元に呼ばれる。

127 ：

ここ意見バラバラなのな

128 ：

>>127
だーからー…
今頃ノコノコ出てきてアゲてんじゃねーよ間抜け。

129 ：

インデックスよりトリガのほうがはやいよ

130 ：

ストアドより自前DBの方が速いよ

131 ：

自前DBよりエイトマンのほうがはやいよ

132 ：

お前より俺の方が早漏だよ

133 ：

(っ´▽｀)っ
っていうか、要するに
インデックスとストアドの両方を採用すればいいんじゃね？
って言えばいいんじゃね？
と半年振りに書き込んだ私に誰か拍手してくれよん☆

134 ：

>>133
>>11

135 ：

>>134
(っ´▽｀)っ
そうだよアホだよ♪

136 ：

>「そんなことやってみなくちゃ分からないだろ！！！ やりもしないで何を
>　言ってるんだよ。
この台詞、精神論を前面に押し出す現場でよく聞くな。

137 ：

その言葉自体には問題ないだろう。
むしろベンチも取らんで決め付ける方が恐ろしい。
結果出てるのに「何かの間違いなんだよ。
こっちの方が早くなんなきゃおかしいんだ！」
とゴリ押しされるのが最悪のパターン。
コードの最適化とかでよく見かける光景。

138 ：

昭和年月米潜水艦放魚雷本命中５本不発小破う幸運艦安川孝雄城本高輝読売孝子用紙梱包後昭和年月日北方海域米潜水艦雷撃受魚雷中沈没案現在駐輪場積極的

139 ：

オカマの思う壺
ttp://megabbs.com/pickles/index.html

140 ：

大抵は「ココまで作っちゃったんだから今更修正できません」と言って聞かないような
バカが書いたクソみたいなコードを書き直させると問題解決する。
（そしてストアドかインデックスかなんてどーでも良くなる）

141 ：

ストアドよりインデックスよりマシンスペック上げた方が速いよ

142 ：

ユーザが必要な内容を全部記憶したほうが速いよ

143 ：

>>139
御堂岡の知人クレーマー三浦秀之

144 ：

いまOTN http://otn.oracle.co.jp/ 見に行ったら、
メニューのドロップダウンリストが広告のFlashの下にもぐり込んで見えねえ。

145 ：

結局、結果は聞けないんだろうか...
んもしかして上司が勝ったんじゃねぇの？

146 ：

かなり古い発言引っ張り出してなんなんだが、
>>63の
>primary key (項目A, 項目B)の構成のテーブルで
>項目Bだけで検索してたというのがあったよ。
って、この場合、項目Bのみのインデックスがあったほうが性能が
向上するというのは分かるが、主キーインデックス（項目Aと項目Bの複合インデックス）も
まったく役に立たないってわけではないよね？
俺なんか勘違いしてる？

147 ：

>>146
それで唯一索引が使われる可能性があるとすると
SELECTやWHEREで項目Aと項目Bしか使わないパターン。
データ部を全件スキャンするより索引を全件スキャンしたほうが、
物理的に読み込むボリュームが少なくて済む。
例）　SELECT 項目A, 項目B FROM ... WHERE 項目B = ?
 

148 ：

では、項目Bでソートして読み出すときは？
主キーインデックスって役に立ってる？

149 ：

ぜんぜん

150 ：

マジで！？
ショック・・・・・・

151 ：

かなりショック

152 ：

手持ちのDB2だとINDEX使って少しでも実行コスト下げる努力してるけど。
RDBMSによって動作は違うとｵﾓ

153 ：

パフォーマンスあげるために両方やっとけばいいんじゃね？
で終わりだろ

154 ：

>>1 の上司が、
「もういいよ。オレがインデックス張ってやるから、まあ見てから言えよ。な？」
と言ってるんだから、
「そうですか、じゃあ、お願いします。」と進言して放置。
少ししてから、ニヤニヤしながら、
「どうでしたか？速くなりました？」と聞きに行くのが正解。

155 ：

インデックスの無い検索をループで繰り返すストアドは遅い。
インデックスの知識が無いやつがストアド書くなって思う。
あと数値を集計して表示の加工する際に同じことができる場合なら
たいていJOINよりUNION ALLの方が速い。これも理由はインデックス。

156 ：

そんな単純な話じゃねーよｗ
インデックスは付けたって使われるとは限らない。
使われないインデックスは、データの無駄でしかない。
また、インデックスを使ったからといって早くなるとは限らない。
どういうときにインデックスが使われて、効果があるかを熟知した上で、
インデックスがちゃんと使われるような、SQL（ストアド含む）を書く。
SQL（ストアド）ってのは迷路のようなものだよ。
普通に進めば長く時間がかかる。インデックスは、その迷路に
壁を一つか二つかあけることができる。どこに壁をあけ、どういうルートを通るか
全体を見て考えないといけない。
SQLとストアドもな。クライアントとサーバーのどちらでどういう処理が動いて
どれだけのデータが転送されるかってのを考えないと、どちらが速いかなんて答えは出ない。

157 ：

迷路ってほど難解でもないと思うが。
つか、普通に考えればストアドとインデックスとどっちか速いかなんて
無意味な議論しないとｵﾓ

158 ：

煙突とダイヤモンドでどちらが高いかという命題に近いな

159 ：

データの分布が変わったらインデックスが有効じゃなくなるとかあるだろ。
常に正しい答えなんてねーよ。

160 ：

　　　　　　　　　　　　　　　　　　,　-‐ '　´￣￣　｀ヽ、
　　　　　　　　　　　　　　　　／　　　　　　　　　　　　｀ ー- ､
　　　　　　　　　　　　　　／　　　　　　　　　　　　　　　　　　}
　　　　　　　　　　　　　/　　　　　　　　　　　　　　　　 __,.　‐ﾍ
　　　　　　　　　　　　/　　　　　　　　 ｆ＿＿,　 -‐ ' ´:.:.:.:.:.:.:.:.:|
　　　　　　　　　　　 /　　　　　　　　　!:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:}
　　　　　　　　　　　 |　　　　　　　　　ｉ::.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:, ＜＼
　　　　　　　　　　　 |　　　　　　　　　|:.:.:.:.＿_ ,:: 　-‐: !｢／`ｉ:.!ヽ＞
　　　　　　　　　　　 |　　　　　　　　 √: : : ::ィ! ⌒ｉﾊ: :ﾘ xぇｖ!:!: }
　　　　　　　　　　　 |　　　　　　　 イ: : : : :/ﾚ斗z-　Ｖ　ﾄﾘ /リV
　　　　　　　　　　　 |　　　　　　　 ｲｲ: :.ｲ/ / んﾊ　　　 ﾋ! {
　　　　　　　　　　　∧　　　　　　　ｉ |イ: |　ヽ v少 　 　 '　 !　ストアドよりインデックスの方が
　　　　　　　　　　 /　　　　　　　　ﾑﾍ: : |　 ､､　　　 __,.　 人　　速いんだよ
　　　　　　　　　　/　　 ／　　　　/: ﾊ !: |、　　　｢　 ノ, ｲ　　!
　 　 　 　 　　　　|_ ／　　　　　 /: !: | |: :!､ ＞　､　 ィ! :.|　 / _＿__
　　　　　　　　　/　　　　　　　 /: :/!: ﾄﾍ: '!￣.ソ介トヽ: :|／/ / /　＼
　　　　　　　　 /　　　　　　　 /: //:ノ:::::|: !ﾆ　ノ|::|C} |: :|　(つ ｉ　/　,ﾉ
　 　 　 　　　 /　　　　　　　 /:: 彡へ::::::|: |:::＼イ::フ^|: :|　 `７'ｰ-イ　　　　〜　♪
　　　　　　　/　　　　　　 ／:.∠　　 /〇}: |＜:::>イ::!　!: |.√〈　　 ,ﾊ
　　　　　　/　　　　　　イ:.:∠二二.ﾒ､ / |: |`''く:::::|＼! |: |::|　　＼/　!　　　／)
　　　　　/　　　　　　/　|://　　　厶ノ　 |: |　　∨＿ﾊ.|: !∧　　　＼|　 ／／
　　　　/　　　　　　　!　 |:/　　　 む'　　 |: |　　　＼_ソ|: |:::::＼　　　|∠∠ 、
　　　/　　　　　　　　　　|　　､　　　　　　|:ﾘ　　　 |:::!::::| :|＼:::::＼／　ー-- }
　　/　　　　　　　　　　　|　　　＼　　　　从　　　 |::::!:::!从　 ＞r'　　　､ ヽ.ﾉ
　 ∧　　　　　　　　　　　ﾄ､　　　 　ー―へ　　　 |::/リ　 ／::|　|　　　rくソ
　/::::＼ 　 　 　 　　　　　|　ヽ　　　　　　　　ヽ　/:/　 ／::::::::|　|ー‐' |
　＼::::::::＼　　　　　　　　|　　|　　　　　　　　 レ'⌒￣　|:::::::::|　|　　　!

161 ：

drop index に罪悪感を感じるようになるとは思わなかった

162 ：

>>156
どっかのＩＴコンサルを名乗る連中みたいな発言だな。たとえ話や抽象論だけで、
要は何をすればいいのか結局現場まかせみたいな。
>インデックスは付けたって使われるとは限らない。
インデックスって、使う/使わないの二択しかないんだから当たり前の話。
>使われないインデックスは、データの無駄でしかない。
正論です。とはいえ、インデックス容量をケチるほどかつかつのハードウェア
設計も珍しいですが。
>また、インデックスを使ったからといって早くなるとは限らない。
これまた正論。帳票など大量のレコードを結合するときは、インデックスを
使うよりもハッシュジョインのほうが早いですからね。
>どういうときにインデックスが使われて、効果があるかを熟知した上で、
>インデックスがちゃんと使われるような、SQL（ストアド含む）を書く。
こういう部分がプログラマの腕の見せ所でもあるんだろうが、実際はそんな
優秀な人間ばっか集めれるわけじゃあるまいし。びっくりするぐらい雑な
ＳＱＬを書くベテランが大勢いるのが現実なわけで。
>SQL（ストアド）ってのは迷路のようなものだよ。
>普通に進めば長く時間がかかる。インデックスは、その迷路に
>壁を一つか二つかあけることができる。どこに壁をあけ、どういうルートを通るか
>全体を見て考えないといけない。
わかったような、わからないような、見事に煙に巻く美文だな。
翻訳すると、「ＳＱＬで全件検索すると遅いから、インデックスというミニ
テーブルを参照してデータを検索する機能を使うと、あたかも本の目次を
見て目的のページを開くかのごとく素早く検索できます」ということ？
>SQLとストアドもな。クライアントとサーバーのどちらでどういう処理が動いて
>どれだけのデータが転送されるかってのを考えないと、どちらが速いかなんて答えは出ない。
能書きはいいから両方速くしてください、でＦＡ？

>>154
似たようなことをやった記憶がある。ＳＱＬの話じゃないけどね。
で、予想どおりトンチンカンなものが出来上がってた。
さらに恐ろしいのは、それが成果物として存在感を出して、後続作業はこれと
矛盾しないようにしなければいけないという制約ができたこと。

163 ：

>>156
>使われないインデックスは、データの無駄でしかない
>>162
>正論です。とはいえ、インデックス容量をケチるほどかつかつのハードウェア
>設計も珍しいですが。
容量よりも更新コストを気にするだろ、普通・・・

164 ：

集合操作をまったく理解していない
コボラーが書いたような無駄に長いストアドは勘弁してほしいな。

165 ：

SQLを書いてからインデックスを張れば無問題。
いまどきオプティマイザがどこにインデックス張ればいいのか教えてくれる。

166 ：

>>165
>SQLを書いてからインデックスを張れば無問題。
SQLを書く前の、テーブル設計する時点でどこにインデックスが必要か考えとくもんだろ？
ついでに言えば、インデックスを張ると更新が遅くなることは知ってるよな？
>いまどきオプティマイザがどこにインデックス張ればいいのか教えてくれる。
最近のオプティマイザは賢くなって最適な実行計画をたてるらしいが、それでも
インデックスをどこに張るかアドバイスまでしてくれるのは初耳だな。
ちなみに、オプティマイザって何をする機能なのかは知ってるよな？

167 ：

なんかagaってたから見てみれば．．．
>>166の言う通りではあるな。>>165みたいな見解が蔓延るから性能問題が後を絶たない。
>>162も一年前のレス触るなよ

168 ：

そもそもストアドもインデックスも必要だから存在するんだよ。
正しくテーブル設計した上で、両方とも適切に使わないと、
実用的なシステムは作れない。

169 ：

すれ違いで申し訳ありませんが、
主キーとインデックスは、全く同じ状況で全く同じ項目に張られている場合(かつ、主キーもしくはインデックスのみの指定で検索された場合)
どちらが早いのでしょうか。
お分かりになられる方が居られましたらご教授よろしくお願いいたします。

170 ：

それはDBに依存するな

171 ：

>>169
>すれ違いで申し訳ありませんが
低姿勢なら何やっても許されるとでも思ってんのか、この間抜けは。

172 ：

>>169
スレ違いドアホ
>>171
プッツンバカ亀
終了

173 ：

岡田外務大臣ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!
h‍ttp‍:‍/‍/‍q‍b5.2‍ch.net/t‍est/rea‍d.cgi‍/sak‍u2ch/1256‍630318/1

早く記念カキコしないと埋まっちゃうｗｗｗ

174 ：

初心者なのでよくわからないのですが、ストアドでインデックス使ったらいいんじゃないの？？？

175 ：

一度やらせてみてください！

176 ：

昨今ストアドを使う意味は、どっちかっていうとセキュロティ強化だろ。

177 ：

セキュロティｗ
>>174
>>11

178 ：

>>169
>すれ違いで申し訳ありませんが、
>主キーとインデックスは、全く同じ状況で全く同じ項目に張られている場合(かつ、主キーもしくはインデックスのみの指定で検索された場合)
>どちらが早いのでしょうか。
>お分かりになられる方が居られましたらご教授よろしくお願いいたします。
主キーとインデックスが「全く同じ状況で」全く同じ項目に張られている場合、ということを具体的に説明してください。
主キーとは論理的な概念でインデックスとは通常物理的な概念です。なので比較はできません。
主キーインデックスと主キーでないインデックスが同じ状況で張られるという事を、すなわち「主キーの代わりに一意キーを張る」ということを意味している事と解釈すると、主キーの方が速いです。
（そうでない実装があったら教えてください。）
但し、その場合、全く同じ状況ではありません。理由は上に書いた通りです。（実装が異なります）

179 ：

ストアドって何よ？

180 ：

保守

181 ：2013/04/29

プラズマで解決