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

1 ：NAME IS NULL：04/09/02 23:11 ID:???.net

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

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

138 ：NAME IS NULL：2006/07/11(火) 21:43:45 ID:5xEL92un.net

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

139 ：NAME IS NULL：2007/01/27(土) 07:26:59 ID:???.net

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

140 ：NAME IS NULL：2007/01/28(日) 23:32:31 ID:???.net

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

141 ：NAME IS NULL：2007/07/16(月) 16:13:22 ID:???.net

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

142 ：NAME IS NULL：2007/07/17(火) 20:06:40 ID:???.net

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

143 ：NAME IS NULL：2007/08/04(土) 13:15:04 ID:khSU9cys.net

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

144 ：NAME IS NULL：2007/08/18(土) 14:06:49 ID:???.net

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

145 ：NAME IS NULL：2007/08/19(日) 01:13:00 ID:???.net

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

146 ：NAME IS NULL：2008/02/08(金) 23:00:34 ID:5lKQqYPb.net

かなり古い発言引っ張り出してなんなんだが、
>>63の
>primary key (項目A, 項目B)の構成のテーブルで
>項目Bだけで検索してたというのがあったよ。

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

147 ：NAME IS NULL：2008/02/09(土) 01:30:49 ID:???.net

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

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

148 ：NAME IS NULL：2008/02/09(土) 23:30:07 ID:hcQ04snf.net

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

149 ：NAME IS NULL：2008/02/10(日) 05:41:25 ID:???.net

ぜんぜん

150 ：NAME IS NULL：2008/02/10(日) 14:07:29 ID:o71MNKp9.net

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

151 ：NAME IS NULL：2008/06/05(木) 14:39:40 ID:OmaPyoR8.net

かなりショック

152 ：NAME IS NULL：2008/06/07(土) 10:48:14 ID:???.net

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

153 ：NAME IS NULL：2008/06/11(水) 11:55:35 ID:???.net

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

154 ：NAME IS NULL：2008/06/24(火) 17:11:38 ID:???.net

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

155 ：NAME IS NULL：2008/07/25(金) 02:08:34 ID:pIJlJ9Ry.net

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

156 ：NAME IS NULL：2008/07/26(土) 02:39:06 ID:???.net

そんな単純な話じゃねーよｗ

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

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

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

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

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

157 ：NAME IS NULL：2008/07/27(日) 01:00:22 ID:???.net

迷路ってほど難解でもないと思うが。

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

158 ：NAME IS NULL：2008/07/27(日) 11:58:38 ID:???.net

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

159 ：NAME IS NULL：2008/07/30(水) 21:27:38 ID:???.net

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

160 ：NAME IS NULL：2008/11/03(月) 08:38:51 ID:???.net

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

161 ：NAME IS NULL：2008/11/14(金) 23:44:11 ID:???.net

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

162 ：NAME IS NULL：2009/07/21(火) 03:34:29 ID:9pmi0kw9.net

>>156

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

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

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

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

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

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

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

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

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

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

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

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

能書きはいいから両方速くしてください、でＦＡ？


>>154

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

163 ：NAME IS NULL：2009/07/22(水) 03:06:00 ID:???.net

>>156
>使われないインデックスは、データの無駄でしかない
>>162
>正論です。とはいえ、インデックス容量をケチるほどかつかつのハードウェア
>設計も珍しいですが。

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

164 ：NAME IS NULL：2009/07/23(木) 01:24:08 ID:DfQXlsWj.net

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

165 ：NAME IS NULL：2009/07/23(木) 21:41:01 ID:???.net

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

166 ：NAME IS NULL：2009/07/24(金) 00:33:08 ID:W2V4yxbD.net

>>165

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

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

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

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

167 ：NAME IS NULL：2009/07/24(金) 10:32:38 ID:lZumjjk/.net

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

168 ：NAME IS NULL：2009/08/22(土) 11:32:22 ID:/H1vAtQw.net

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

169 ：NAME IS NULL：2009/09/02(水) 00:02:05 ID:???.net

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

170 ：NAME IS NULL：2009/09/02(水) 03:29:46 ID:???.net

それはDBに依存するな

171 ：NAME IS NULL：2009/09/03(木) 10:40:06 ID:???.net

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

172 ：NAME IS NULL：2009/09/04(金) 06:09:50 ID:???.net

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

終了

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

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



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

174 ：NAME IS NULL：2009/12/15(火) 22:24:09 ID:???.net

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

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

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

176 ：NAME IS NULL：2009/12/16(水) 12:38:11 ID:???.net

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

177 ：NAME IS NULL：2009/12/17(木) 15:20:07 ID:???.net

セキュロティｗ

>>174
>>11

178 ：NAME IS NULL：2011/02/16(水) 02:02:13 ID:???.net

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

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

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

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

179 ：電脳プリオン 忍法帖【Lv=40,xxxPT】(1+0：8) 【36.7m】 ：2013/02/03(日) 18:08:40.22 ID:???.net ?PLT(12080)

ストアドって何よ？

180 ：NAME IS NULL：2013/04/24(水) 18:26:03.20 ID:tyOf/uG0.net

保守

181 ：NAME IS NULL：2013/04/29(月) 09:48:30.69 ID:???.net

プラズマで解決

182 ：NAME IS NULL：2017/12/29(金) 11:54:33.48 ID:dtNZwIie.net

誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒　『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。

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

HG3O2RUU4Z

183 ：NAME IS NULL：2018/02/15(木) 00:36:45.31 ID:???.net

☆ 日本の、改憲をしましょう。現在、衆議員と参議院の両院で、
改憲議員が３分の２を超えております。『憲法改正国民投票法』、
でググってみてください。国会の発議はすでに可能です。
平和は勝ち取るものです。お願い致します。☆☆

184 ：NAME IS NULL：2023/08/21(月) 20:37:28.56 ID:???.net

ムシャムシャしてやった、今ははんすうしている

185 ：NAME IS NULL：2023/09/12(火) 12:15:19.39 ID:6d8/jH5RR

軍事費GDP比4%超でNATOにまで加盟しようとしていたウクライナは周辺国に脅威視されて攻撃されたわけだか゛．世界最惡の腐敗利権国家日本も
軍事費倍増させて周辺国に脅威視されようとマッチポンプ戰爭利権屋とベッ夕リの岸田異次元増税文雄か゛必死た゛な
ウクライナで市民への攻撃カ゛‐だの停電カ゛―た゛の戦爭犯罪ガ―だの白々しいか゛．戰争なんだから当たり前た゛ろ
曰本に絨毯爆撃して原爆まて゛落とした世界最悪のならす゛者國家なんて．いまだに新型戰略爆撃機とか発表してるだろ
軍事施設だけ爆撃とかあり得ないし、要するに戰略ってのは戦争となればこいつを使って‐般市民の家屋を焼き尽くすって意味た゛からな
國民を人間の盾にして、女こども以外逃亡(出國)禁止にして戦わせて、他國まで巻き込んでまで利権に執着してるキチカ゛イナセ゛レンスキ−を
いまた゛に引きずり降ろさないあたり．戦闘民族として現状を受け入れて．むしろリアルサハ゛ゲ−を楽しんでると理解するのか゛正解
世界最悪の腐敗利権国家曰本は軍事費セ゛口にして，ポ一ランドのように国民に武器を持たせて扱い方を訓練する個人防衛国ヘと移行しよう!
(羽田)ttps://www.call4.jp/info.php?type=items&id=I0000062 , ttps://haneda-project.jimdofree.com/
(成田)ttps://n-souonhigaisosyoudan.amebaownd.com/
(テ口組織)ttps://i.imgur.com/hnli1ga.jpeg

186 ：NAME IS NULL：2023/09/20(水) 17:30:00.65 ID:???.net

ふー、ついてない日だな

187 ：NAME IS NULL：2023/11/23(木) 19:06:58.29 ID:uHLqXzmsb

摂津市の15０2万円回収断念とかこの方法なら取れると考えたクソ公務員による共謀詐取だろ
振込まれたほうは何の落ち度もないんだからクソ公務員が全額弁済するのが筋、返して欲しければ弁護士だの法的手続きだの税金で
費用かけてクソ公務員に給料という名目で追い銭までくれてやって返還請求作業するのではなくクソ公務員が勝手に自腹でどうにかしろや
個人情報漏洩の代名詞マイナンバーの入力とか送金とか手作業て゛やるという發想が何ひとつ価値生産て゛きない無能害虫丸出し
100個程度のデータ作成すらプログラム作るのが健常者だろうに作っては壊しの無意味な作業まで名目に血税を盗み取り続けてるのが実態
土に潜って根を食って草木を枯らすコガネムシの幼虫と何ひとつ変わらないクソ公務員は退治するたひ゛に国民の生活は向上するわけた゛が
市役所職員なんて大抵市内に住んでるんた゛し後をつけるなりして居住地を特定するとか余裕だわな
窓口でクソ公務員の鼻骨を砕く勇者はリスペクトだが来世がマトモな社会になるほどのヰンパクトを考えよう！
(羽田)ttps://www.call４.jp/info.phP?typｅ＝items&id=I00０0062 , ttps://haneda-ΡrojеCt.jimdofrее.Com/
(成田)tTps:/／n-souonhigaisosyoudan.amеbaownd.com/
［テロ組織)ttps://i.imgur.com／hnli1ga.jрeg