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

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

(っ´▽｀)っ
っていうか、要するに
インデックスとストアドの両方を採用すればいいんじゃね？
って言えばいいんじゃね？

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

>>133
>>11

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

>「そんなことやってみなくちゃ分からないだろ！！！ やりもしないで何を
>　言ってるんだよ。

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

その言葉自体には問題ないだろう。
むしろベンチも取らんで決め付ける方が恐ろしい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ぜんぜん

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

かなりショック

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>156

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

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

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

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

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

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

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

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

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

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

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

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

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


>>154

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

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

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

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

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

>>165

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

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

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

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

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

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

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

それはDBに依存するな

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

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

終了

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



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

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

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

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

セキュロティｗ

>>174
>>11

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

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

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

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

ストアドって何よ？

保守

プラズマで解決