No.151
ストアドよりインデックスのほうが速いよ
レス数: 185
概要: かなりショック
No.152
RDBMSによって動作は違うとｵﾓ
No.153
で終わりだろ
No.154
の上司が、
「もういいよ。オレがインデックス張ってやるから、まあ見てから言えよ。な？」
と言ってるんだから、
「そうですか、じゃあ、お願いします。」と進言して放置。
少ししてから、ニヤニヤしながら、
「どうでしたか？速くなりました？」と聞きに行くのが正解。
No.155
インデックスの知識が無いやつがストアド書くなって思う。
あと数値を集計して表示の加工する際に同じことができる場合なら
たいていJOINよりUNION ALLの方が速い。これも理由はインデックス。
No.156
インデックスは付けたって使われるとは限らない。
使われないインデックスは、データの無駄でしかない。
また、インデックスを使ったからといって早くなるとは限らない。
どういうときにインデックスが使われて、効果があるかを熟知した上で、
インデックスがちゃんと使われるような、SQL（ストアド含む）を書く。
SQL（ストアド）ってのは迷路のようなものだよ。
普通に進めば長く時間がかかる。インデックスは、その迷路に
壁を一つか二つかあけることができる。どこに壁をあけ、どういうルートを通るか
全体を見て考えないといけない。
SQLとストアドもな。クライアントとサーバーのどちらでどういう処理が動いて
どれだけのデータが転送されるかってのを考えないと、どちらが速いかなんて答えは出ない。
No.157
つか、普通に考えればストアドとインデックスとどっちか速いかなんて
無意味な議論しないとｵﾓ
No.158
No.159
常に正しい答えなんてねーよ。
No.160
／ ｀ ー- ､
／ }
/ __,. ‐ﾍ
/ ｆ＿＿, -‐ ' ´:.:.:.:.:.:.:.:.:|
/ !:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:}
| ｉ::.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:, ＜＼
| |:.:.:.:.＿_ ,:: -‐: !｢／`ｉ:.!ヽ＞
| √: : : ::ィ! ⌒ｉﾊ: :ﾘ xぇｖ!:!: }
| イ: : : : :/ﾚ斗z- Ｖ ﾄﾘ /リV
| ｲｲ: :.ｲ/ / んﾊ ﾋ! {
∧ ｉ |イ: | ヽ v少 ' ! ストアドよりインデックスの方が
/ ﾑﾍ: : | ､､ __,. 人 速いんだよ
/ ／ /: ﾊ !: |、 ｢ ノ, ｲ !
|_ ／ /: !: | |: :!､ ＞ ､ ィ! :.| / _＿__
/ /: :/!: ﾄﾍ: '!￣.ソ介トヽ: :|／/ / / ＼
/ /: //:ノ:::::|: !ﾆ ノ|::|C}|: :| (つ ｉ / ,ﾉ
/ /:: 彡へ::::::|: |:::＼イ::フ^|: :| `７'ｰ-イ 〜 ♪
/ ／:.∠ /〇}: |＜:::>イ::! !: |.√〈 ,ﾊ
/ イ:.:∠二二.ﾒ､ / |: |`''く:::::|＼! |: |::| ＼/ ! ／)
/ / |:// 厶ノ |: | ∨＿ﾊ.|: !∧ ＼| ／／
/ ! |:/ む' |: | ＼_ソ|: |:::::＼ |∠∠ 、
/ | ､ |:ﾘ |:::!::::| :|＼:::::＼／ ー-- }
/ | ＼ 从 |::::!:::!从 ＞r' ､ ヽ.ﾉ
∧ ﾄ､ ー―へ |::/リ ／::| | rくソ
/::::＼ | ヽ ヽ /:/ ／::::::::| |ー‐' |
＼::::::::＼ | | レ'⌒￣ |:::::::::| | !
No.161
No.162
どっかのＩＴコンサルを名乗る連中みたいな発言だな。たとえ話や抽象論だけで、
要は何をすればいいのか結局現場まかせみたいな。
>インデックスは付けたって使われるとは限らない。
インデックスって、使う/使わないの二択しかないんだから当たり前の話。
>使われないインデックスは、データの無駄でしかない。
正論です。とはいえ、インデックス容量をケチるほどかつかつのハードウェア
設計も珍しいですが。
>また、インデックスを使ったからといって早くなるとは限らない。
これまた正論。帳票など大量のレコードを結合するときは、インデックスを
使うよりもハッシュジョインのほうが早いですからね。
>どういうときにインデックスが使われて、効果があるかを熟知した上で、
>インデックスがちゃんと使われるような、SQL（ストアド含む）を書く。
こういう部分がプログラマの腕の見せ所でもあるんだろうが、実際はそんな
優秀な人間ばっか集めれるわけじゃあるまいし。びっくりするぐらい雑な
ＳＱＬを書くベテランが大勢いるのが現実なわけで。
>SQL（ストアド）ってのは迷路のようなものだよ。
>普通に進めば長く時間がかかる。インデックスは、その迷路に
>壁を一つか二つかあけることができる。どこに壁をあけ、どういうルートを通るか
>全体を見て考えないといけない。
わかったような、わからないような、見事に煙に巻く美文だな。
翻訳すると、「ＳＱＬで全件検索すると遅いから、インデックスというミニ
テーブルを参照してデータを検索する機能を使うと、あたかも本の目次を
見て目的のページを開くかのごとく素早く検索できます」ということ？
>SQLとストアドもな。クライアントとサーバーのどちらでどういう処理が動いて
>どれだけのデータが転送されるかってのを考えないと、どちらが速いかなんて答えは出ない。
能書きはいいから両方速くしてください、でＦＡ？
>>154
似たようなことをやった記憶がある。ＳＱＬの話じゃないけどね。
で、予想どおりトンチンカンなものが出来上がってた。
さらに恐ろしいのは、それが成果物として存在感を出して、後続作業はこれと
矛盾しないようにしなければいけないという制約ができたこと。
No.163
>使われないインデックスは、データの無駄でしかない
>>162
>正論です。とはいえ、インデックス容量をケチるほどかつかつのハードウェア
>設計も珍しいですが。
容量よりも更新コストを気にするだろ、普通・・・
No.164
コボラーが書いたような無駄に長いストアドは勘弁してほしいな。
No.165
いまどきオプティマイザがどこにインデックス張ればいいのか教えてくれる。
No.166
>SQLを書いてからインデックスを張れば無問題。
SQLを書く前の、テーブル設計する時点でどこにインデックスが必要か考えとくもんだろ？
ついでに言えば、インデックスを張ると更新が遅くなることは知ってるよな？
>いまどきオプティマイザがどこにインデックス張ればいいのか教えてくれる。
最近のオプティマイザは賢くなって最適な実行計画をたてるらしいが、それでも
インデックスをどこに張るかアドバイスまでしてくれるのは初耳だな。
ちなみに、オプティマイザって何をする機能なのかは知ってるよな？
No.167
>>166
の言う通りではあるな。
>>165
みたいな見解が蔓延るから性能問題が後を絶たない。
>>162
も一年前のレス触るなよ
No.168
正しくテーブル設計した上で、両方とも適切に使わないと、
実用的なシステムは作れない。
No.169
主キーとインデックスは、全く同じ状況で全く同じ項目に張られている場合(かつ、主キーもしくはインデックスのみの指定で検索された場合)
どちらが早いのでしょうか。
お分かりになられる方が居られましたらご教授よろしくお願いいたします。
No.170
No.171
>すれ違いで申し訳ありませんが
低姿勢なら何やっても許されるとでも思ってんのか、この間抜けは。
No.172
スレ違いドアホ
>>171
プッツンバカ亀
終了
No.173
http://qb5.2ch.net/test/read.cgi/saku2ch/1256630318/1
早く記念カキコしないと埋まっちゃうｗｗｗ
No.174
No.175
No.176
No.177
>>174
>>11
No.178
>すれ違いで申し訳ありませんが、
>主キーとインデックスは、全く同じ状況で全く同じ項目に張られている場合(かつ、主キーもしくはインデックスのみの指定で検索された場合)
>どちらが早いのでしょうか。
>お分かりになられる方が居られましたらご教授よろしくお願いいたします。
主キーとインデックスが「全く同じ状況で」全く同じ項目に張られている場合、ということを具体的に説明してください。
主キーとは論理的な概念でインデックスとは通常物理的な概念です。なので比較はできません。
主キーインデックスと主キーでないインデックスが同じ状況で張られるという事を、すなわち「主キーの代わりに一意キーを張る」ということを意味している事と解釈すると、主キーの方が速いです。
（そうでない実装があったら教えてください。）
但し、その場合、全く同じ状況ではありません。理由は上に書いた通りです。（実装が異なります）
No.179
No.180
No.181
No.182
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。
グーグル検索⇒『宮本のゴウリエセレレ』
HG3O2RUU4Z
No.183
改憲議員が３分の２を超えております。『憲法改正国民投票法』、
でググってみてください。国会の発議はすでに可能です。
平和は勝ち取るものです。お願い致します。☆☆
No.184
No.185
