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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


>>154

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

終了

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



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



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

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

1751742009/12/16(水) 00:43:47ID:???

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

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

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

>>174
>>11

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

主キーとインデックスが「全く同じ状況で」全く同じ項目に張られている場合、ということを具体的に説明してください。

主キーとは論理的な概念でインデックスとは通常物理的な概念です。なので比較はできません。

主キーインデックスと主キーでないインデックスが同じ状況で張られるという事を、すなわち「主キーの代わりに一意キーを張る」ということを意味している事と解釈すると、主キーの方が速いです。
(そうでない実装があったら教えてください。)
但し、その場合、全く同じ状況ではありません。理由は上に書いた通りです。(実装が異なります)

ストアドって何よ?

180NAME IS NULL2013/04/24(水) 18:26:03.20ID:tyOf/uG0
保守

181NAME IS NULL2013/04/29(月) 09:48:30.69ID:???
プラズマで解決

182NAME IS NULL2017/12/29(金) 11:54:33.48ID:dtNZwIie
誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。

グーグル検索⇒『宮本のゴウリエセレレ』

HG3O2RUU4Z

183NAME IS NULL2018/02/15(木) 00:36:45.31ID:???
☆ 日本の、改憲をしましょう。現在、衆議員と参議院の両院で、
改憲議員が3分の2を超えております。『憲法改正国民投票法』、
でググってみてください。国会の発議はすでに可能です。
平和は勝ち取るものです。お願い致します。☆☆

新着レスの表示
レスを投稿する