5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

1 :NAME IS NULL:04/09/02 23:11 ID:???
なんかね、データベースからデータを取得して VB で簡単な加工して、
書き戻すっていう更新処理があったのよ。当然、C/S 間のピンポン多発で
非常に遅いでやんす。で、「バッチ更新はストアドで書き直したらどうですか?」って
上司に言ったわけです。勇気をふりしぼって。

そしたら「ストアドよりインデックスのほうが速いよ」って。(゚Д゚)ハァ?
「クエリ単体の実行時間は 50ms 以下なので遅いのは呼び出しのオーバーヘッドが…」
「データベースが遅いのはね。インデックスなんだよ。たとえば、君の言う
50ms がインデックスを工夫することで 20ms になったら倍以上に速くなるんだよ。」
「いや、50ms が 20ms になっても体感できないと思うんですが…」
「そんなことやってみなくちゃ分からないだろ!!! やりもしないで何を
 言ってるんだよ。インデックスは奥が深いんだよ」
「いまでも主キー指定での取得になっていて…」
「もういいよ。オレがインデックス張ってやるから、まあ見てから言えよ。な?」

2 :NAME IS NULL:04/09/03 12:36 ID:???
もっと分かりやすく文章かけよ
何がいいたいのかワカンネ

3 :NAME IS NULL:04/09/03 21:24 ID:???
スレ建てないで雑談スレに書けよ

4 :NAME IS NULL:04/09/04 00:23 ID:???
>>1 削除以来出しとけよ。

5 :NAME IS NULL:04/09/04 17:00 ID:???
なんだか言っていることが面白いよね。
本当雑談だよ。

入社1年目の初心者でしょ。

そのあとの話の展開がどうなったのか教えてちょ。


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

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

8 :NAME IS NULL:04/09/11 08:05:18 ID:???
…まあ見てから言えよ。な?

>>1の上司は熊先生に似たナイスガイ(ウラヤマスィ

9 :NAME IS NULL:04/09/11 15:25:04 ID:???
こんな感じか? たとえば、半角全角混在の文字項目を全角に統一する。
(1) レコードセットを取得する。
(2) VBの関数を使って、1レコードを全角に変換して、1レコード分の update 発行。

このようなユーザーの意思を必要としない処理はストアドにして一括更新したほうがいいね。
(2) を何万回も繰り返すのはアホ。

10 :NAME IS NULL:04/09/19 02:06:28 ID:Kqi5X+Sq
>>1
そろそろ結果を報告しなよ

11 :NAME IS NULL:04/10/19 15:09:20 ID:???
>>7
プロシジャで処理することと
インデックスを張ることは
背反しません。
>経験的に。
無知なまま経験を積んでも実になりませんよ。

12 :NAME IS NULL:04/10/24 01:21:41 ID:???
>1

ミドルウェアの記述がないので、Java環境での話をすると
以前調べた時、NWとミドルを含めたオーバーヘッドは1,2msだった。
数万件単位で大量件数を処理するならSP化は有効だけど
オンライン系で遅いなら他にボトルネックがあると思われる。

もしかして、毎回コネクション張りにいっているという
オチじゃないだろうな・・

ちなみに、更新系はC/S環境でもSPに匹敵する性能がでるよ。
参照系は、SPには勝てんが。。

13 :NAME IS NULL:04/11/14 19:15:55 ID:4kWmAqHu
質問:
3層c/sでアプリサーバーとDBサーバーが同じノード上にある場合はストアド使わなくても
パフォーマンス出るんでしょうか?

14 :NAME IS NULL:04/11/14 19:55:23 ID:cp9oa1wi
http://jbbs.livedoor.jp/sports/352/

15 :NAME IS NULL:04/11/14 21:55:38 ID:mxx8koKz
>>13
ストアドの方が僅かにでも速くなることが多い

16 :NAME IS NULL:04/11/14 23:50:30 ID:???
>>2-15
まぁそんなにムキるな。どーせ釣りだろ(w

17 :NAME IS NULL:04/11/15 15:01:28 ID:???
どうしようって言うくらい馬鹿ばかりだなこのスレ。

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


18 :NAME IS NULL:04/11/15 18:56:55 ID:???
>>1の文章が理解できません・・・
どれが1の発言で、どれが上司の発言なんでしょうか?



19 :NAME IS NULL:04/11/16 02:03:25 ID:???
>17
たぶん正解だな。

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

20 :NAME IS NULL:04/11/20 17:19:37 ID:o6mGJOoN
>12
>もしかして、毎回コネクション張りにいっているという
>オチじゃないだろうな・・

そんな気がす・・・

21 :NAME IS NULL:04/11/24 21:01:08 ID:???
>>20
実はデータリンクが IEEE-488。

22 :a:04/11/27 09:59:43 ID:SLvZscV9
何回もSQLを発行してない?最近みたプログラムで、カーソルのル
ープ使ってその中でさらに問い合わせを発行して、何万回もSQLを
発行するようなプログラムを見た。
結局、テーブルを結合して一回で問い合わせが完了するようにSQL
を書き直したら、嘘みたいに早くなったよ。工夫してみれば?

23 :NAME IS NULL:04/11/28 19:39:51 ID:???
22> ちみはまだ経験が足りん

24 :NAME IS NULL:04/11/30 02:20:37 ID:???
>>23
なんで?1の書き込みには詳細が書いてないから、
22の意見が出てもおかしくないような気が。

25 :NAME IS NULL:04/11/30 05:13:06 ID:???
結合するより、何回もSQL発行した場合も早いこともあるわけで 一概には言えないと?>>23

26 :NAME IS NULL:04/11/30 12:15:45 ID:???
>>25
結合するだけで出来るような問い合わせが
自力ループより遅くなるとは考えにくいが。
-- 副問い合わせを含む問い合わせが
-- 自力ループより遅くなる事はある

27 :NAME IS NULL:04/12/01 01:16:29 ID:???
今更ながら、1の書き込みを読み直してみるとw

問題点を通信のオーバーヘッドではないか?と考えているので
>>22さんの意見は、良いところをついているのではないかな。

昔の話だけど実際にそのようなケースを生産性・品質向上
取り組みの副作用として見たことがあるよ。

その時は共通チームが業務共通系の処理を共通関数として
提供してしまった?ため、それに関わるようなマスタテーブルは
そんな処理になってしまった。

最近はマシンも速いから一見遅くはないけど、負荷の高い処理って
なかなか問題が表面化しないで、地雷みたいに埋まってるんだよねぇ。。

28 :NAME IS NULL:04/12/01 11:07:14 ID:???
>>27
問題とするところがまったく違うんじゃないか?

>>1 の上司が莫迦だって話だろう?スレタイからしても。

29 :NAME IS NULL:04/12/24 16:02:31 ID:tUfbN2jS
>>28
たしかに問題とする次元が違ってると思う。

 |非常に遅いでやんす。で、「バッチ更新はストアドで書き直したらどうですか?」って
 |上司に言ったわけです。勇気をふりしぼって。

インデックス…問い合わせ効率を向上させるためのもの(ツメ見出し)
ストアド…SQL文をプリコンパイル済みにして通常のSQLが問い合わせ前に行う
 プリコンパイル作業等に掛かる時間的ロスを軽減する

でなかったか?


バッチ処理するのにインデックスあったら効率悪いので
インデックスをdrop

バッチ

インデックスを(再びCreate)

(シェアードテーブル化できないならSELECT文でキャッシュに)

だろう…


もっと詳しい人どうぞ。(w

30 :NAME IS NULL:04/12/25 01:07:50 ID:otLeELiy
文面から察するに、SELECTして加工してUPDATEを繰り返してるんでしょ。
加工する内容次第だけど、インデックスよりはストアドじゃないかな。

でも、何もいじらずサーバのメモリ追加した方が楽だったり。

31 :NAME IS NULL:04/12/25 01:16:16 ID:ROEABQwC
>>1はACCESSの話してるんだよ。

32 :NAME IS NULL:04/12/25 09:37:19 ID:ZHJuMAXb
クエリ単体で50ms以下で遅いってことは、
無駄にSQL何回も発行してるのが原因なので
ストアドとかインデックスより、まず処理を見直すべき。
単純なSQLをそのままストアド化しても意味無いよ。
あとインデックスはストアドに対しても有効だよ。
ストアドの実行計画みたことある?

33 :NAME IS NULL:04/12/25 10:36:17 ID:???
(DB使うのにVB使うのやめれ)

(今の時代アプリにオプソでも良いからDB必ず使え)

∴VB捨てれ
話はそれからだ

34 :NAME IS NULL:04/12/25 11:59:43 ID:???
また、VB も使えない厨が来たのか ?

まず、「(DB使うのにVB使うのやめれ) 」の具体的理由を書いてみそ。

35 :NAME IS NULL:04/12/25 12:05:48 ID:ROEABQwC
ストアドよりインデックスのほうがてっとり早いのは常識。
議論の余地なし。

36 :NAME IS NULL:04/12/25 13:16:43 ID:???
VBアプリでメモリ多く使うと落ちる。
画面のコンポーネントべたべた貼る程度でキョドる。

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

38 :NAME IS NULL:04/12/25 15:33:56 ID:???
>仕方がないのでクライアント側に一旦対象のレコードのキーをすべて書き出して、
これをDB内で済ませろ

39 :NAME IS NULL:04/12/25 15:58:31 ID:???
>29
プリコンパイル(静的SQL)とストアドプロシジャは全く別のものだよ。

40 :NAME IS NULL:04/12/25 16:23:54 ID:???
>>38
tempテーブルが使えるならそうするんだけど残念ながらOracle8なので使えません。
ログ運用してるんで通常テーブルをワークには使いたくないのです。

>>39
別の概念ではあるがプリコンパイルされないストアドって見たことはないですね。

41 :NAME IS NULL:04/12/25 18:13:53 ID:???
>>40
俺は見たことあるぞ?

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

43 :NAME IS NULL:04/12/25 19:54:30 ID:???
>>36
OS かお前のマシンがしょぼいんじゃねーか ?

あるいは、バグバグしてるコンポーネント使いまくりとかな。

44 :NAME IS NULL:04/12/25 20:20:49 ID:M5IwN66m
http://plaza.rakuten.co.jp/batrowa/
ここに行ってゲームのことを一から学ぶ<丶`Д´>ニダー

45 :NAME IS NULL:04/12/25 20:37:50 ID:Uriq8RBM
>>36
自分の技術の無さをVBのせいにするな


46 :NAME IS NULL:04/12/26 17:35:00 ID:???
そもそもバッチ更新なのにコンポーネントは全く関係なし。
アプリに負担をかけることすら間違い。

それとクライアントに一端処理を移すとのことだけれども
ストアドやインデックス云々より、DBの構造を見直した
方が早いよ。

47 :NAME IS NULL:04/12/29 22:22:41 ID:???
ストアドよりインデックスのほうがてっとり早いのは常識。
議論の余地なし。


48 :NAME IS NULL:04/12/29 23:02:50 ID:???
ボトルネックを調べてみるのにまず手っ取り早い索引から調べるというのは
同意だが、実際の対策としてストアドとインデックスを比べるのは意味はない。
まったく別物だからなぁ。
要領を得ないことをいう部下を信用しないのは上司の基本だと思うな(笑)

49 :NAME IS NULL:04/12/30 04:22:19 ID:XdHOAyNH
>>1を叩くのは2チャンネラの基本だと思うな(笑) ←笑って付けるだけでキモヲタ風味になる。

50 :NAME IS NULL:05/01/01 17:25:50 ID:+DDcZPR8
つーか どんな業務なのかを教えろよまず。



51 :NAME IS NULL:05/01/04 23:28:36 ID:gtuR+WFj
>>46-47
オマイラ、論点がずれてる。

>>48
正解


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


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

53 :NAME IS NULL:05/01/05 12:16:39 ID:???
>>52
>よく読め。

>>1
>「いまでも主キー指定での取得になっていて…」

莫迦麦価

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

55 :NAME IS NULL:05/01/05 17:22:32 ID:???
なんつーか、やれやれですな。

>>54
>何で主キー指定して取得してるのにストアドなんだよ?
>意味無いだろ。
ストアドプロシジャの利点は、RDB サーバの _プロセス内で
処理が閉じている_ 点にある。その為、>>1 の指摘する
>C/S 間のピンポン多発で非常に遅いでやんす。
が解消される事が期待できる。

一方、主キーには _既にインデックスは作成されている為_、
二重にインデックスを張る行為には _全く意味がない_。

56 :NAME IS NULL:05/01/05 17:52:21 ID:???
>>55
同意。やれやれだよ。
>>54あたり本気なのかネタなのかすら判別がつかん。

何でこんな基礎的な話で議論になるのか…。


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

58 :NAME IS NULL:05/01/06 08:33:10 ID:???
>>57
( ゚Д゚)ポカーン

考えれば分かる話だろう。
じゃなくて、そこんとこ詳細に説明してみ。
どんな珍説なのか是非聞いてみたい。

59 :NAME IS NULL:05/01/06 10:24:06 ID:???
>>58
わからないなら黙ってろ。

60 :NAME IS NULL:05/01/06 10:52:57 ID:???
>>59
負け犬乙

61 :NAME IS NULL:05/01/06 11:30:58 ID:???
>>57 の考え、休むに似たり」

>よってインデックスが正しい。

>>55
>二重にインデックスを張る行為には _全く意味がない_。

62 :NAME IS NULL:05/01/06 12:00:46 ID:???
>>61
m9(^Д^)プギャー ぜんぜん意味わかってねー。

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

64 :NAME IS NULL:05/01/06 15:01:59 ID:???
>>57
想像するに…
・一行ずつ取得ではなく、複数行持ってきてUPDATEはループで回せ。
・UPDATE一発でやれ
のどちらかを言いたいのだと思うけど、それじゃ出来ない処理なんて
いくらでもある。そう言うときの為にストアドがある。

そもそも
「ストアドが存在するDBMSにもかかわらずクライアントでバッチ更新」
なんて仕様が出てくる時点で間違い。

>>63
> 最近のは大丈夫ですよね?
そうでもないよ。

65 :NAME IS NULL:05/01/06 15:14:53 ID:???
>>64
物事には順序がある。
一行ずつ取得してる新人に、いきなりストアドでやれとは言わない。
ストアドなどという前にやることがあるだろう。

66 :NAME IS NULL:05/01/06 17:01:57 ID:???
>>65
VBでバッチ処理が書けてストアドだと書けないなんて事があるか
どう考えてもストアドの方が簡単だろう。

単なる怠慢。

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

68 :NAME IS NULL:05/01/07 19:30:04 ID:???
やかん

69 :NAME IS NULL:05/01/07 19:52:36 ID:???
>>67
Oracle で、FOR UPDATE 付きの問い合わせをしてるなら
それは仕様。ROWID 使え。
Oracle じゃないなら知らん。
つか、スレ違い。

70 :NAME IS NULL:05/01/07 19:54:15 ID:???
>>67
コミット後にカーソルをオープンしたままにする方法はないの?
大抵のDBMSならできるはずだけど。

71 :NAME IS NULL:05/01/08 00:52:36 ID:/A2kgL9D
そこでインデックスですよ。

72 :NAME IS NULL:05/01/12 23:38:32 ID:???
>>57でキーボードに茶を吹いたよ。 どうしてくれる。
>>64はきっと釈迦のような慈悲の心を持っているんだろうな。

73 :NAME IS NULL:05/01/13 00:41:48 ID:???
確かに>>57って笑えるw


74 :NAME IS NULL:05/01/13 23:21:13 ID:Yo88RG9E
>>70
DB2とかのやり方をまねしちゃだめ。
カーソルループ中にCOMMITする発想はあんましよくない。
途中でこけたら元に戻せなくなる。

そういう場合はロールバックセグメントを大きくとっておくのがOracleのやりかた。



75 :NAME IS NULL:05/01/14 03:07:55 ID:???
えせOracleの香りがぷんぷんする

76 :NAME IS NULL:05/01/14 07:41:07 ID:???
>>74
最後の一行は要らなかったな

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

78 :NAME IS NULL:05/01/16 02:14:22 ID:???
>>77

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



79 :NAME IS NULL:05/01/16 10:18:16 ID:???
>>78
その通り。

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



80 :NAME IS NULL:05/01/16 12:25:52 ID:???
そのあたり、セーブポイントでどうにかできないのでしょうか。

81 :NAME IS NULL:05/01/16 19:27:34 ID:???
そもそもセーブポイントって、どういうものか理解しているのか?


82 :77:05/01/16 20:28:02 ID:???
>>78,79
カーソルループの中で整合性が取れるケースって、珍しくはないよ。
いくつか思いつくけどね。
例えば、受注テーブルを基に、物流システムへ渡す出荷指示データ
を作成するバッチ処理とか。
受注テーブルの出荷指示フラグと出荷日を基にカーソルループでまわす
場合。で、ループの中では、受注テーブルの出荷指示フラグを更新し、在庫
テーブル更新、出荷指示テーブル作成とかやってる場合、処理する受注伝票
単位で整合性が取れてれば問題ないというケース。

>管理が非常に難しくなるし、
どこまでコミットしたかの情報も一々記録しないといけないからパフォーマンスも悪くなる。

正直、意味が良くわからん。多分、管理が非常にむずかしくなるってのは、
どこまでコミットしたかを把握したいという意味なんだろうけど。

すでにコミットしたデータは、整合性が取れてるわけだから、基本的には気に
する必要はない。プログラムの不具合で、コミットしたデータの信頼性が損なわれている
場合でも、テーブルに更新時のタイムスタンプと最終更新PGMのIDでも持たせて
おけば、調査できるだろ。
基本的にはバグなんだから、それよりロックの期間が長くなるというデメリット
のほうが俺はいやだね。


83 :NAME IS NULL:05/01/17 09:39:55 ID:???
>>82
彼らの言っているのは

> ループの中では、受注テーブルの出荷指示フラグを更新し、在庫
> テーブル更新、出荷指示テーブル作成とかやってる場合

この「ループの中」の途中でコミットしてしまうと言うケースを想定して
話をしているんだよ。
「カーソルループ」と言う言葉に捕らわれすぎで話の本質が分かってない。

84 :77:05/01/17 10:52:52 ID:1w1sWpKp
>>83
そうなのか?だとすると確かにレアケースだが。

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

85 :NAME IS NULL:05/01/17 11:13:38 ID:???
>>84
67に対しては69でFA出てる。
そこから先の話はトランザクション内でのコミットの是非についてだろ。

86 :NAME IS NULL:05/01/17 11:15:32 ID:???
訂正
67に対しては70でFA出てる



87 :77:05/01/17 12:47:35 ID:1w1sWpKp
>>85
>そこから先の話はトランザクション内でのコミットの是非についてだろ。
そんなのまずいに決まってんじゃん。トランザクションの1つの要件は、
整合性を確保できる最小単位であることだ。(原子性、一貫性)

俺が77で言っているのは、カーソルループ1回単位が1トランザクション
の場合と、カーソルループ全体が1トランザクションの場合の話。

>>67に対しては70でFA出てる
やっぱり話の本質が分かってないのは、お前のほうだと思うがな。俺は、
70に対する返答(74)に対して、77で返答してんだから。
どこから、トランザクション内でのコミットの是非についてになったん
だ。

88 :NAME IS NULL:05/01/17 13:26:16 ID:???
>>87
言ってる意味がさっぱりわからん
とりあえず落ち着け

89 :!= 77:05/01/17 13:58:39 ID:???
>>88
二段落目読んでも解らないとなるとヤバイ。

90 :NAME IS NULL:05/01/17 16:00:24 ID:2hmp7s5X
そもそも同列に語ることがおかしいってスレでいいんだよな。
・ストアド化による性能向上
ミドルウェア及び通信等のコスト減を目的

・インデックスをきちんとすること
データに対するアクセス経路の最適化を目的

91 :NAME IS NULL:05/01/17 17:36:33 ID:???
>>90
>>67 以降、違う話に花が咲いています。

92 :NAME IS NULL:05/01/18 01:10:45 ID:???
>>90

>>91の言うように、話題が変わってます。
カーソルループで大量更新をする場合の話。

>>87,88
想定している状況がそれぞれ違ってるみたいだから
ちょっとこじれかけてるけど、めずらしくまともな議論
に育ちそうだからマターリいこーぜー。



93 :77:05/01/31 01:00:05 ID:???
すごい遅レスだが。

>そんなのまずいに決まってんじゃん。トランザクションの1つの要件は、
>整合性を確保できる最小単位であることだ。(原子性、一貫性)

これは、トランザクションは整合性を確保する最小単位だから、
トランザクション内部でのコミットは有り得ないということが
言いたかった。


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

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

96 :NAME IS NULL:2005/04/05(火) 23:35:00 ID:???
>>94
>OracleのSPはネーティブコードではなくインタプリタのようです
んな事ぁちょっと考えれば解(ry

97 :NAME IS NULL:2005/04/06(水) 01:54:36 ID:???
>>94-96
PL/SQLはネイティブコンパイルもできる

98 :NAME IS NULL:2005/04/06(水) 03:50:58 ID:???
>>97
そういえばそんなのがありましたね。Cコンパイラが別に必要だったり、
設定がめんどかったり、SQLなどのDBアクセス部分には効果がなかったり
で結局使いませんでした。
>DBの問い合わせではなくロジックをしこたま実行するプログラムを作ったの
こういうのには効果がありそうです。

99 :NAME IS NULL:2005/04/06(水) 20:12:09 ID:???
ここが一番ヘビーユーザーが多いみたいだね

教えて欲しいのだが、行レベルロックに対応しているDBはオラクル
以外にありますか?

100 :NAME IS NULL:2005/04/06(水) 20:23:32 ID:???
>>99
SQLServer


101 :NAME IS NULL:2005/04/06(水) 20:24:16 ID:???
>>99
Access2000/2003

102 :NAME IS NULL:2005/04/06(水) 20:45:26 ID:???
>>100
いやMSSQLは、テーブルごとロックする
読み取り以外はロック待ち状態になった気がした

103 :NAME IS NULL:2005/04/06(水) 21:05:03 ID:PM6d5T4G
>>102
はぁ?

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


104 :NAME IS NULL:2005/04/06(水) 21:18:53 ID:???
>103
あれって、インデックスが無いと
ページになるんじゃなかったけ?
勘違いかな。

105 :U ◆CZtFsGiu0c :2005/04/06(水) 21:37:45 ID:???
>>104
「テーブルスキャン」と混同してない?

SQLServerは7.0から行ロックをサポートしてるし、Sybaseは11.9.xから。
DB2は知らんけど、今時行ロックサポートしてない商用RDBMSなんて相手に
されないと思うけど。

106 :NAME IS NULL:2005/04/06(水) 22:41:20 ID:???
>>99
おまいはここが質問スレかどうかも解らんのか?

107 :NAME IS NULL:2005/04/08(金) 00:58:03 ID:???
>1 を読む限りここは愚痴スレだね。

108 :NAME IS NULL:2005/04/09(土) 02:07:58 ID:???
10年ぐらい前なんでよく憶えてないが、DB2も行ロックするよ

109 :NAME IS NULL:2005/04/09(土) 20:41:32 ID:???
運用担当が行ロックをありがたがるのは理解できるのだが、
開発担当が行ロックじゃなきゃ使えないとか言ってるのを聞くと
それは技術力がないという以前の単なるへたれなだけのような気がする。

110 :NAME IS NULL:2005/04/09(土) 20:46:11 ID:???
>>109
はぁ?


111 :NAME IS NULL:2005/05/29(日) 22:48:27 ID:GvDeAxP+
>ストアドよりインデックスのほうが速いよ (<−−スレタイ)

それぞれ、どのようにした速度が改善されるのかを考えたほうがいい

ストアドによる処理速度の向上は以下の2点による。
1.プログラムがサーバーにあるためサーバークライアント間の
  回線経由のデータ転送をなくすことによる速度アップである
2.SQLを中間言語に落とすことにより、インタープリタの必要がない

インデックスによる速度改善とは以下
3.ディスクアクセスを少なくする。

ストアドを使うときの注意事項
4.ストアドはLAN環境だと1.の速度アップは期待できない。低速の
  ネットワークならば期待できる。
5.ストアドのプログラムの管理が面倒。デバックしにくいDBもある。

結論を言うと、
6.インデックスによる速度アップはすべきである。
  (というか、これをしないと普通は、実運用に耐えられない)
7.ストアドによる速度アップはLAN環境でのC/Sの場合は
  期待できない。低速回線経由のC/Sならば期待できる。
8.ロジックを共有するという目的ならばストアドの使用は可。

以上かな。

112 :NAME IS NULL:2005/05/29(日) 23:32:52 ID:???
> 111

あんたが正解。
クエリー投げてカーソル範囲を確定するのに
一番影響するのがインデックスだし、
インデックスをつけても、変わらないのがC/S間の
データ転送速度。(FETCHね)
ストアドなら、ネットワークインフラの性能が
左右するが、クライアントからのちまちました
カーソルFETCHかますより、全レコードを配列変数などで
アウトパラメタとして一括送信したほうが早い場合も
ある。

全て条件付きのケースバイケースだけど、
「クエリを実行してカーソルを確定する」部分と
「カーソルからレコードを取得する」部分の違いは
ちゃんと理解したほうがいいですね。

FETCHしたレコードが大して多くないのに、処理が遅いとかって、
大体クエリの効率が悪く、カーソル処理の場合FETCH − LOOPではなく
その前のクエリ実行が遅かったりする。
そんなときは、いくらストアドにしてもだめ。
SELECT文の実行計画を調べて、その対処としてインデックスを
付与することが明らかであれば、そうすべし。




113 :NAME IS NULL:2005/05/30(月) 01:27:21 ID:???
> ストアドによる速度アップはLAN環境での C/S の場合は期待できない。

これには反論あり。100Mbps の LAN であってもサーバーカーソルを使うと
著しいパフォーマンス低下をもたらす。参照系だけでファイアーホースを
使うならともかく、サーバーカーソルを使ってフェッチ&アップデートを
繰り返すなんて LAN でもやるべきではない。

>>1 はフェッチ&アップデートの多発で速度低下していると言っているのだろう。
その考えは結構正しい。LAN であってもユーザーの判断・操作を
必要としない一括更新はストアドにすべし。クライアントプロセスで
更新する必要性がなかろう。

114 :NAME IS NULL:2005/05/30(月) 01:30:39 ID:???
ここは「頭の悪そうな発言をする」スレですか?

115 :NAME IS NULL:2005/05/30(月) 01:37:20 ID:???
>>111
ストアドの利点はもう1つあって、それは静的SQL構文であること。
既にコンパイル済みなので、SQL文の構文解析の手間が無いので高速。


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


116 :NAME IS NULL:2005/05/30(月) 02:15:18 ID:???
>>114
愚痴スレだって事に気付かない莫迦がスレ伸ばしてたからね。
で、前の方の書き込み見ずに蒸し返す莫迦がageやがった、と。

117 :NAME IS NULL:2005/05/30(月) 13:43:06 ID:???
>>114
いいえ、的外れなことをそれっぽく言ってみようとするスレです

118 :NAME IS NULL:2005/05/30(月) 15:22:59 ID:RbWMGJ3o
>>114, 116, 117
君たちの見解を知りたいものだ

119 :NAME IS NULL:2005/05/30(月) 16:24:32 ID:???
クソスレの有効利用でいいことじゃないか。何を粘着してるんだか。

120 :112:2005/05/30(月) 23:48:57 ID:???
> 113
DBサーバ上のローカルアクセスならLAN性能は関係ないぞ。
サーバマシン単体の性能なら話はわかるが。


121 :NAME IS NULL:2005/05/31(火) 00:08:44 ID:???
>>120
いや同一ホスト内であってもサーバーカーソルを別プロセスから
動かすってのは、かなりの高コスト処理なのよ。

ADO なんかで MoveNext とかするでしょ。サーバーカーソルの場合
そのたびにサーバーカーソルを動かすためのストアドとかが裏で呼ばれるわけ。

122 :NAME IS NULL:2005/05/31(火) 01:00:55 ID:???
だから、FETCHもサーバ(プロセス)でやって、データを一括で返せば?
SQL Server のストアドは詳しくないが、アウトパラメタで配列
返すことはできたっけ?

123 :NAME IS NULL:2005/05/31(火) 10:56:31 ID:Pwnlm8uV
>>122
クライアントカーソルの事だな。


124 :NAME IS NULL:2005/05/31(火) 18:14:44 ID:???
>>122
SQL Serverの場合は1クエリーで処理できないような問い合わせは
Temptテーブルを仲介させると効率よく処理できる。
table型はストアドの外では使えなかったと思う。

125 :NAME IS NULL:2005/07/25(月) 16:44:44 ID:cf5vlPiQ
似たような速度の話を一つ。

3000件(5フィールド)のデータがあるとして、
1.ストアド内でカーソルで回して使用
2.最初に配列に取り込みカウンタで回して使用

上の数字は、適当なものだけど、こゆ場合は、どっちが速いの?
カーソルって1レコード分のデータのみメモリにあるのかな?
DBアクセスしてるとしたら、2.のが速そうなんだけど。
だれか分かる人〜




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

127 :NAME IS NULL:2005/10/15(土) 20:13:42 ID:QwLPLcWX
ここ意見バラバラなのな

128 :NAME IS NULL:2005/10/15(土) 22:04:11 ID:???
>>127
だーからー…
今頃ノコノコ出てきてアゲてんじゃねーよ間抜け。

129 :NAME IS NULL:2005/10/17(月) 02:06:04 ID:???
インデックスよりトリガのほうがはやいよ

130 :NAME IS NULL:2005/10/17(月) 19:48:53 ID:M18TRkZF
ストアドより自前DBの方が速いよ

131 :NAME IS NULL:2005/10/17(月) 22:02:24 ID:???
自前DBよりエイトマンのほうがはやいよ

132 :NAME IS NULL:2005/10/18(火) 09:19:25 ID:???
お前より俺の方が早漏だよ


133 :側近中の側近 ◆0351148456 :2006/04/22(土) 22:27:38 ID:???
(っ´▽`)っ
っていうか、要するに
インデックスとストアドの両方を採用すればいいんじゃね?
って言えばいいんじゃね?

と半年振りに書き込んだ私に誰か拍手してくれよん☆

134 :阿呆ですか?:2006/04/22(土) 23:49:15 ID:???
>>133
>>11

135 :側近中の側近 ◆0351148456 :2006/04/23(日) 08:07:05 ID:???
>>134
(っ´▽`)っ
そうだよアホだよ♪

136 :NAME IS NULL:2006/05/03(水) 21:35:45 ID:???
>「そんなことやってみなくちゃ分からないだろ!!! やりもしないで何を
> 言ってるんだよ。

この台詞、精神論を前面に押し出す現場でよく聞くな。



137 :NAME IS NULL:2006/06/05(月) 20:52:04 ID:???
その言葉自体には問題ないだろう。
むしろベンチも取らんで決め付ける方が恐ろしい。

結果出てるのに「何かの間違いなんだよ。
こっちの方が早くなんなきゃおかしいんだ!」
とゴリ押しされるのが最悪のパターン。
コードの最適化とかでよく見かける光景。

138 :NAME IS NULL:2006/07/11(火) 21:43:45 ID:5xEL92un
昭和年月米潜水艦放魚雷本命中5本不発小破う幸運艦安川孝雄城本高輝読売孝子用紙梱包後昭和年月日北方海域米潜水艦雷撃受魚雷中沈没案現在駐輪場積極的

139 :NAME IS NULL:2007/01/27(土) 07:26:59 ID:???
オカマの思う壺
ttp://megabbs.com/pickles/index.html

140 :NAME IS NULL:2007/01/28(日) 23:32:31 ID:???
大抵は「ココまで作っちゃったんだから今更修正できません」と言って聞かないような
バカが書いたクソみたいなコードを書き直させると問題解決する。
(そしてストアドかインデックスかなんてどーでも良くなる)


141 :NAME IS NULL:2007/07/16(月) 16:13:22 ID:???
ストアドよりインデックスよりマシンスペック上げた方が速いよ

142 :NAME IS NULL:2007/07/17(火) 20:06:40 ID:???
ユーザが必要な内容を全部記憶したほうが速いよ

143 :NAME IS NULL:2007/08/04(土) 13:15:04 ID:khSU9cys
>>139
御堂岡の知人クレーマー三浦秀之

144 :NAME IS NULL:2007/08/18(土) 14:06:49 ID:???
いまOTN http://otn.oracle.co.jp/ 見に行ったら、
メニューのドロップダウンリストが広告のFlashの下にもぐり込んで見えねえ。

145 :NAME IS NULL:2007/08/19(日) 01:13:00 ID:???
結局、結果は聞けないんだろうか...
んもしかして上司が勝ったんじゃねぇの?

146 :NAME IS NULL:2008/02/08(金) 23:00:34 ID:5lKQqYPb
かなり古い発言引っ張り出してなんなんだが、
>>63
>primary key (項目A, 項目B)の構成のテーブルで
>項目Bだけで検索してたというのがあったよ。

って、この場合、項目Bのみのインデックスがあったほうが性能が
向上するというのは分かるが、主キーインデックス(項目Aと項目Bの複合インデックス)も
まったく役に立たないってわけではないよね?
俺なんか勘違いしてる?



147 :NAME IS NULL:2008/02/09(土) 01:30:49 ID:???
>>146
それで唯一索引が使われる可能性があるとすると
SELECTやWHEREで項目Aと項目Bしか使わないパターン。
データ部を全件スキャンするより索引を全件スキャンしたほうが、
物理的に読み込むボリュームが少なくて済む。

例) SELECT 項目A, 項目B FROM ... WHERE 項目B = ?
 

148 :NAME IS NULL:2008/02/09(土) 23:30:07 ID:hcQ04snf
では、項目Bでソートして読み出すときは?
主キーインデックスって役に立ってる?

149 :NAME IS NULL:2008/02/10(日) 05:41:25 ID:???
ぜんぜん

150 :NAME IS NULL:2008/02/10(日) 14:07:29 ID:o71MNKp9
マジで!?
ショック・・・・・・

151 :NAME IS NULL:2008/06/05(木) 14:39:40 ID:OmaPyoR8
かなりショック

152 :NAME IS NULL:2008/06/07(土) 10:48:14 ID:???
手持ちのDB2だとINDEX使って少しでも実行コスト下げる努力してるけど。
RDBMSによって動作は違うとオモ

153 :NAME IS NULL:2008/06/11(水) 11:55:35 ID:???
パフォーマンスあげるために両方やっとけばいいんじゃね?
で終わりだろ

154 :NAME IS NULL:2008/06/24(火) 17:11:38 ID:???
>>1 の上司が、
「もういいよ。オレがインデックス張ってやるから、まあ見てから言えよ。な?」
と言ってるんだから、
「そうですか、じゃあ、お願いします。」と進言して放置。
少ししてから、ニヤニヤしながら、
「どうでしたか?速くなりました?」と聞きに行くのが正解。

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


156 :NAME IS NULL:2008/07/26(土) 02:39:06 ID:???
そんな単純な話じゃねーよw

インデックスは付けたって使われるとは限らない。
使われないインデックスは、データの無駄でしかない。

また、インデックスを使ったからといって早くなるとは限らない。

どういうときにインデックスが使われて、効果があるかを熟知した上で、
インデックスがちゃんと使われるような、SQL(ストアド含む)を書く。

SQL(ストアド)ってのは迷路のようなものだよ。
普通に進めば長く時間がかかる。インデックスは、その迷路に
壁を一つか二つかあけることができる。どこに壁をあけ、どういうルートを通るか
全体を見て考えないといけない。

SQLとストアドもな。クライアントとサーバーのどちらでどういう処理が動いて
どれだけのデータが転送されるかってのを考えないと、どちらが速いかなんて答えは出ない。

157 :NAME IS NULL:2008/07/27(日) 01:00:22 ID:???
迷路ってほど難解でもないと思うが。

つか、普通に考えればストアドとインデックスとどっちか速いかなんて
無意味な議論しないとオモ

158 :NAME IS NULL:2008/07/27(日) 11:58:38 ID:???
煙突とダイヤモンドでどちらが高いかという命題に近いな

159 :NAME IS NULL:2008/07/30(水) 21:27:38 ID:???
データの分布が変わったらインデックスが有効じゃなくなるとかあるだろ。
常に正しい答えなんてねーよ。

160 :NAME IS NULL:2008/11/03(月) 08:38:51 ID:???
                  , -‐ ' ´ ̄ ̄ `ヽ、
                /            ` ー- 、
              /                  }
             /                 __,. ‐ヘ
            /         f__,  -‐ ' ´:.:.:.:.:.:.:.:.:|
            /         !:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:}
            |         i::.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:, <\
            |         |:.:.:.:.__ ,::  -‐: !「/`i:.!ヽ>
            |         √: : : ::ィ! ⌒iハ: :リ xぇv!:!: }
            |        イ: : : : :/レ斗z- V トリ /リV
            |        イイ: :.イ/ / んハ    ヒ! {
           ∧       i |イ: | ヽ v少     '  ! ストアドよりインデックスの方が
           /        ムヘ: : |  、、    __,.  人  速いんだよ
          /   /    /: ハ !: |、   「  ノ, イ  !
            |_ /      /: !: | |: :!、 > 、  ィ! :.|  / ____
         /        /: :/!: トヘ: '! ̄.ソ介トヽ: :|// / / \
         /        /: //:ノ:::::|: !ニ ノ|::|C} |: :| (つ i / ,ノ
          /        /:: 彡へ::::::|: |:::\イ::フ^|: :|  `7'ー-イ    〜 ♪
       /       /:.∠   /〇}: |<:::>イ::! !: |.√〈   ,ハ
      /      イ:.:∠二二.メ、 / |: |`''く:::::|\! |: |::|  \/ !   /)
     /      / |://   厶ノ  |: |  ∨_ハ.|: !∧   \|  //
    /       !  |:/    む'   |: |   \_ソ|: |:::::\   |∠∠ 、
   /          |  、      |:リ    |:::!::::| :|\:::::\/ ー-- }
  /           |   \    从    |::::!:::!从  >r'   、 ヽ.ノ
  ∧           ト、     ー―へ    |::/リ  /::| |   rくソ
 /::::\            | ヽ        ヽ /:/  /::::::::| |ー‐' |
 \::::::::\        |  |         レ'⌒ ̄ |:::::::::| |   !

161 :NAME IS NULL:2008/11/14(金) 23:44:11 ID:???
drop index に罪悪感を感じるようになるとは思わなかった

162 :NAME IS NULL:2009/07/21(火) 03:34:29 ID:9pmi0kw9
>>156

どっかのITコンサルを名乗る連中みたいな発言だな。たとえ話や抽象論だけで、
要は何をすればいいのか結局現場まかせみたいな。

>インデックスは付けたって使われるとは限らない。

インデックスって、使う/使わないの二択しかないんだから当たり前の話。

>使われないインデックスは、データの無駄でしかない。

正論です。とはいえ、インデックス容量をケチるほどかつかつのハードウェア
設計も珍しいですが。

>また、インデックスを使ったからといって早くなるとは限らない。

これまた正論。帳票など大量のレコードを結合するときは、インデックスを
使うよりもハッシュジョインのほうが早いですからね。

>どういうときにインデックスが使われて、効果があるかを熟知した上で、
>インデックスがちゃんと使われるような、SQL(ストアド含む)を書く。

こういう部分がプログラマの腕の見せ所でもあるんだろうが、実際はそんな
優秀な人間ばっか集めれるわけじゃあるまいし。びっくりするぐらい雑な
SQLを書くベテランが大勢いるのが現実なわけで。

>SQL(ストアド)ってのは迷路のようなものだよ。
>普通に進めば長く時間がかかる。インデックスは、その迷路に
>壁を一つか二つかあけることができる。どこに壁をあけ、どういうルートを通るか
>全体を見て考えないといけない。

わかったような、わからないような、見事に煙に巻く美文だな。
翻訳すると、「SQLで全件検索すると遅いから、インデックスというミニ
テーブルを参照してデータを検索する機能を使うと、あたかも本の目次を
見て目的のページを開くかのごとく素早く検索できます」ということ?

>SQLとストアドもな。クライアントとサーバーのどちらでどういう処理が動いて
>どれだけのデータが転送されるかってのを考えないと、どちらが速いかなんて答えは出ない。

能書きはいいから両方速くしてください、でFA?


>>154

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

163 :NAME IS NULL:2009/07/22(水) 03:06:00 ID:???
>>156
>使われないインデックスは、データの無駄でしかない
>>162
>正論です。とはいえ、インデックス容量をケチるほどかつかつのハードウェア
>設計も珍しいですが。

容量よりも更新コストを気にするだろ、普通・・・

164 :NAME IS NULL:2009/07/23(木) 01:24:08 ID:DfQXlsWj
集合操作をまったく理解していない
コボラーが書いたような無駄に長いストアドは勘弁してほしいな。

165 :NAME IS NULL:2009/07/23(木) 21:41:01 ID:???
SQLを書いてからインデックスを張れば無問題。
いまどきオプティマイザがどこにインデックス張ればいいのか教えてくれる。

166 :NAME IS NULL:2009/07/24(金) 00:33:08 ID:W2V4yxbD
>>165

>SQLを書いてからインデックスを張れば無問題。

SQLを書く前の、テーブル設計する時点でどこにインデックスが必要か考えとくもんだろ?
ついでに言えば、インデックスを張ると更新が遅くなることは知ってるよな?

>いまどきオプティマイザがどこにインデックス張ればいいのか教えてくれる。

最近のオプティマイザは賢くなって最適な実行計画をたてるらしいが、それでも
インデックスをどこに張るかアドバイスまでしてくれるのは初耳だな。
ちなみに、オプティマイザって何をする機能なのかは知ってるよな?

167 :NAME IS NULL:2009/07/24(金) 10:32:38 ID:lZumjjk/
なんかagaってたから見てみれば...
>>166の言う通りではあるな。>>165みたいな見解が蔓延るから性能問題が後を絶たない。
>>162も一年前のレス触るなよ

168 :NAME IS NULL:2009/08/22(土) 11:32:22 ID:/H1vAtQw
そもそもストアドもインデックスも必要だから存在するんだよ。
正しくテーブル設計した上で、両方とも適切に使わないと、
実用的なシステムは作れない。

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



170 :NAME IS NULL:2009/09/02(水) 03:29:46 ID:???
それはDBに依存するな

171 :NAME IS NULL:2009/09/03(木) 10:40:06 ID:???
>>169
>すれ違いで申し訳ありませんが
低姿勢なら何やっても許されるとでも思ってんのか、この間抜けは。

172 :NAME IS NULL:2009/09/04(金) 06:09:50 ID:???
>>169
スレ違いドアホ
>>171
プッツンバカ亀

終了

173 :NAME IS NULL:2009/10/29(木) 11:12:53 ID:BZMEXbd0



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



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


174 :NAME IS NULL:2009/12/15(火) 22:24:09 ID:???
初心者なのでよくわからないのですが、ストアドでインデックス使ったらいいんじゃないの???

175 :174:2009/12/16(水) 00:43:47 ID:???

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

176 :NAME IS NULL:2009/12/16(水) 12:38:11 ID:???
昨今ストアドを使う意味は、どっちかっていうとセキュロティ強化だろ。

177 :NAME IS NULL:2009/12/17(木) 15:20:07 ID:???
セキュロティw

>>174
>>11

53 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)