ストアドよりインデックスのほうが速いよ
なんかね、データベースからデータを取得して VB で簡単な加工して、
書き戻すっていう更新処理があったのよ。当然、C/S 間のピンポン多発で
非常に遅いでやんす。で、「バッチ更新はストアドで書き直したらどうですか？」って
上司に言ったわけです。勇気をふりしぼって。
そしたら「ストアドよりインデックスのほうが速いよ」って。(ﾟДﾟ)ﾊｧ?
「クエリ単体の実行時間は 50ms 以下なので遅いのは呼び出しのオーバーヘッドが…」
「データベースが遅いのはね。インデックスなんだよ。たとえば、君の言う
50ms がインデックスを工夫することで 20ms になったら倍以上に速くなるんだよ。」
「いや、50ms が 20ms になっても体感できないと思うんですが…」
「そんなことやってみなくちゃ分からないだろ！！！ やりもしないで何を
言ってるんだよ。インデックスは奥が深いんだよ」
「いまでも主キー指定での取得になっていて…」
「もういいよ。オレがインデックス張ってやるから、まあ見てから言えよ。な？」 >>78,79
カーソルループの中で整合性が取れるケースって、珍しくはないよ。
いくつか思いつくけどね。
例えば、受注テーブルを基に、物流システムへ渡す出荷指示データ
を作成するバッチ処理とか。
受注テーブルの出荷指示フラグと出荷日を基にカーソルループでまわす
場合。で、ループの中では、受注テーブルの出荷指示フラグを更新し、在庫
テーブル更新、出荷指示テーブル作成とかやってる場合、処理する受注伝票
単位で整合性が取れてれば問題ないというケース。
>管理が非常に難しくなるし、
どこまでコミットしたかの情報も一々記録しないといけないからパフォーマンスも悪くなる。
正直、意味が良くわからん。多分、管理が非常にむずかしくなるってのは、
どこまでコミットしたかを把握したいという意味なんだろうけど。
すでにコミットしたデータは、整合性が取れてるわけだから、基本的には気に
する必要はない。プログラムの不具合で、コミットしたデータの信頼性が損なわれている
場合でも、テーブルに更新時のタイムスタンプと最終更新PGMのIDでも持たせて
おけば、調査できるだろ。
基本的にはバグなんだから、それよりロックの期間が長くなるというデメリット
のほうが俺はいやだね。
>>82
彼らの言っているのは
> ループの中では、受注テーブルの出荷指示フラグを更新し、在庫
> テーブル更新、出荷指示テーブル作成とかやってる場合
この「ループの中」の途中でコミットしてしまうと言うケースを想定して
話をしているんだよ。
「カーソルループ」と言う言葉に捕らわれすぎで話の本質が分かってない。 >>83
そうなのか？だとすると確かにレアケースだが。
67の質問ってそういう意味じゃねーと思うがな。実際、DB2,MSSQL,
Oracleもデフォルトじゃコミットしたら、カーソルクローズしちゃう
しな。(SQL92の仕様だからだろうけど。）
69の回答も俺とおんなじ理解だろ。
話の本質が分かってないのは、お前のほうじゃねーかって気がするがな。 >>84
67に対しては69でFA出てる。
そこから先の話はトランザクション内でのコミットの是非についてだろ。 >>85
>そこから先の話はトランザクション内でのコミットの是非についてだろ。
そんなのまずいに決まってんじゃん。トランザクションの1つの要件は、
整合性を確保できる最小単位であることだ。（原子性、一貫性）
俺が77で言っているのは、カーソルループ1回単位が１トランザクション
の場合と、カーソルループ全体が１トランザクションの場合の話。
>>67に対しては70でFA出てる
やっぱり話の本質が分かってないのは、お前のほうだと思うがな。俺は、
70に対する返答(74)に対して、77で返答してんだから。
どこから、トランザクション内でのコミットの是非についてになったん
だ。 >>87
言ってる意味がさっぱりわからん
とりあえず落ち着け >>88
二段落目読んでも解らないとなるとヤバイ。 そもそも同列に語ることがおかしいってスレでいいんだよな。
・ストアド化による性能向上
ミドルウェア及び通信等のコスト減を目的
・インデックスをきちんとすること
データに対するアクセス経路の最適化を目的 >>90
>>67 以降、違う話に花が咲いています。 >>90
>>91の言うように、話題が変わってます。
カーソルループで大量更新をする場合の話。
>>87,88
想定している状況がそれぞれ違ってるみたいだから
ちょっとこじれかけてるけど、めずらしくまともな議論
に育ちそうだからマターリいこーぜー。
すごい遅レスだが。
>そんなのまずいに決まってんじゃん。トランザクションの1つの要件は、
>整合性を確保できる最小単位であることだ。（原子性、一貫性）
これは、トランザクションは整合性を確保する最小単位だから、
トランザクション内部でのコミットは有り得ないということが
言いたかった。
OracleのSPはネーティブコードではなくインタプリタのようです、
ＤＢの問い合わせではなくロジックをしこたま実行するプログラムを作ったの
ですが予想の百倍ぐらい時間がかかりました。
SPそれ自身の実行速度はVBとたいして変わらない印象です、
サーバに中途半端なCPUを使うとPCでVBのほうが早い可能性も
ありです。 >>94
たいていの処理系ではStored ProcedureはP-Codeのような中間言語方式だから
Oracleもそうじゃないかな。一般的にサーバーサイドでCPUを多く使う処理は
避けたほうがいいから問題ないように思う。複雑な処理をしたいならOracle内臓の
JServer VMでJava stored procedureを使うという手もある。こちらはJITでコンパ
イルされるから２回目以降の処理は速い。 >>94
>OracleのSPはネーティブコードではなくインタプリタのようです
んな事ぁちょっと考えれば解（ｒｙ >>94-96
PL/SQLはネイティブコンパイルもできる >>97
そういえばそんなのがありましたね。Cコンパイラが別に必要だったり、
設定がめんどかったり、SQLなどのDBアクセス部分には効果がなかったり
で結局使いませんでした。
＞ＤＢの問い合わせではなくロジックをしこたま実行するプログラムを作ったの
こういうのには効果がありそうです。 ここが一番ヘビーユーザーが多いみたいだね
教えて欲しいのだが、行レベルロックに対応しているDBはオラクル
以外にありますか？ >>100
いやMSSQLは、テーブルごとロックする
読み取り以外はロック待ち状態になった気がした >>102
はぁ？
SQLServer2000であれば行単位のロックが可能だよ。
あまりにも膨大になってくると、ロックエスカレーションを引き起こし表単位のロックになるがな。
>103
あれって、インデックスが無いと
ページになるんじゃなかったけ？
勘違いかな。 >>104
「テーブルスキャン」と混同してない?
SQLServerは7.0から行ロックをサポートしてるし、Sybaseは11.9.xから。
DB2は知らんけど、今時行ロックサポートしてない商用RDBMSなんて相手に
されないと思うけど。 >>99
おまいはここが質問ｽﾚかどうかも解らんのか？ 10年ぐらい前なんでよく憶えてないが、DB2も行ロックするよ 運用担当が行ロックをありがたがるのは理解できるのだが、
開発担当が行ロックじゃなきゃ使えないとか言ってるのを聞くと
それは技術力がないという以前の単なるへたれなだけのような気がする。 >ストアドよりインデックスのほうが速いよ (＜−−スレタイ)
それぞれ、どのようにした速度が改善されるのかを考えたほうがいい
ストアドによる処理速度の向上は以下の２点による。
１．プログラムがサーバーにあるためサーバークライアント間の
回線経由のデータ転送をなくすことによる速度アップである
２．SQLを中間言語に落とすことにより、インタープリタの必要がない
インデックスによる速度改善とは以下
３．ディスクアクセスを少なくする。
ストアドを使うときの注意事項
４．ストアドはＬＡＮ環境だと１．の速度アップは期待できない。低速の
ネットワークならば期待できる。
５．ストアドのプログラムの管理が面倒。デバックしにくいＤＢもある。
結論を言うと、
６．インデックスによる速度アップはすべきである。
（というか、これをしないと普通は、実運用に耐えられない）
７．ストアドによる速度アップはＬＡＮ環境でのＣ／Ｓの場合は
期待できない。低速回線経由のＣ／Ｓならば期待できる。
８．ロジックを共有するという目的ならばストアドの使用は可。
以上かな。 > 111
あんたが正解。
クエリー投げてカーソル範囲を確定するのに
一番影響するのがインデックスだし、
インデックスをつけても、変わらないのがC/S間の
データ転送速度。（FETCHね）
ストアドなら、ネットワークインフラの性能が
左右するが、クライアントからのちまちました
カーソルFETCHかますより、全レコードを配列変数などで
アウトパラメタとして一括送信したほうが早い場合も
ある。
全て条件付きのケースバイケースだけど、
「クエリを実行してカーソルを確定する」部分と
「カーソルからレコードを取得する」部分の違いは
ちゃんと理解したほうがいいですね。
FETCHしたレコードが大して多くないのに、処理が遅いとかって、
大体クエリの効率が悪く、カーソル処理の場合FETCH − LOOPではなく
その前のクエリ実行が遅かったりする。
そんなときは、いくらストアドにしてもだめ。
SELECT文の実行計画を調べて、その対処としてインデックスを
付与することが明らかであれば、そうすべし。
> ストアドによる速度アップはＬＡＮ環境での C/S の場合は期待できない。
これには反論あり。100Mbps の LAN であってもサーバーカーソルを使うと
著しいパフォーマンス低下をもたらす。参照系だけでファイアーホースを
使うならともかく、サーバーカーソルを使ってフェッチ&アップデートを
繰り返すなんて LAN でもやるべきではない。
>>1 はフェッチ&アップデートの多発で速度低下していると言っているのだろう。
その考えは結構正しい。LAN であってもユーザーの判断・操作を
必要としない一括更新はストアドにすべし。クライアントプロセスで
更新する必要性がなかろう。 >>111
ストアドの利点はもう１つあって、それは静的ＳＱＬ構文であること。
既にコンパイル済みなので、ＳＱＬ文の構文解析の手間が無いので高速。
あと高速化とは関係無いけど、バグが発生した場合はＤＢサーバに対して修正するだけで良い。
Ｃ／Ｓシステムほど、その効果が高い。
>>114
愚痴ｽﾚだって事に気付かない莫迦がｽﾚ伸ばしてたからね。
で、前の方の書き込み見ずに蒸し返す莫迦がageやがった、と。 >>114
いいえ、的外れなことをそれっぽく言ってみようとするスレです >>114, 116, 117
君たちの見解を知りたいものだ クソスレの有効利用でいいことじゃないか。何を粘着してるんだか。 > 113
DBサーバ上のローカルアクセスならLAN性能は関係ないぞ。
サーバマシン単体の性能なら話はわかるが。
>>120
いや同一ホスト内であってもサーバーカーソルを別プロセスから
動かすってのは、かなりの高コスト処理なのよ。
ADO なんかで MoveNext とかするでしょ。サーバーカーソルの場合
そのたびにサーバーカーソルを動かすためのストアドとかが裏で呼ばれるわけ。 だから、FETCHもサーバ（プロセス）でやって、データを一括で返せば？
SQL Server のストアドは詳しくないが、アウトパラメタで配列
返すことはできたっけ？ >>122
SQL Serverの場合は１クエリーで処理できないような問い合わせは
Temptテーブルを仲介させると効率よく処理できる。
table型はストアドの外では使えなかったと思う。 似たような速度の話を一つ。
３０００件（５フィールド）のデータがあるとして、
１．ストアド内でカーソルで回して使用
２．最初に配列に取り込みカウンタで回して使用
上の数字は、適当なものだけど、こゆ場合は、どっちが速いの？
カーソルって１レコード分のデータのみメモリにあるのかな？
ＤＢアクセスしてるとしたら、２．のが速そうなんだけど。
だれか分かる人〜
配列にいれると２度手間だからどう考えても遅いよ。
データベースの種類にもよるけど、メモリにあるのはキャッシュされた複数レコード。
SQLをコンパイルしたコードとインデックス位置を保持してるのがカーソル。
読み込みはキャッシュか物理記憶からその情報を元に呼ばれる。 >>127
だーからー…
今頃ノコノコ出てきてアゲてんじゃねーよ間抜け。 (っ´▽｀)っ
っていうか、要するに
インデックスとストアドの両方を採用すればいいんじゃね？
って言えばいいんじゃね？
と半年振りに書き込んだ私に誰か拍手してくれよん☆ >「そんなことやってみなくちゃ分からないだろ！！！ やりもしないで何を
> 言ってるんだよ。
この台詞、精神論を前面に押し出す現場でよく聞くな。
その言葉自体には問題ないだろう。
むしろベンチも取らんで決め付ける方が恐ろしい。
結果出てるのに「何かの間違いなんだよ。
こっちの方が早くなんなきゃおかしいんだ！」
とゴリ押しされるのが最悪のパターン。
コードの最適化とかでよく見かける光景。 昭和年月米潜水艦放魚雷本命中５本不発小破う幸運艦安川孝雄城本高輝読売孝子用紙梱包後昭和年月日北方海域米潜水艦雷撃受魚雷中沈没案現在駐輪場積極的 オカマの思う壺
ttp://megabbs.com/pickles/index.html 大抵は「ココまで作っちゃったんだから今更修正できません」と言って聞かないような
バカが書いたクソみたいなコードを書き直させると問題解決する。
（そしてストアドかインデックスかなんてどーでも良くなる）
ストアドよりインデックスよりマシンスペック上げた方が速いよ いま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も一年前のレス触るなよ そもそもストアドもインデックスも必要だから存在するんだよ。
正しくテーブル設計した上で、両方とも適切に使わないと、
実用的なシステムは作れない。 すれ違いで申し訳ありませんが、
主キーとインデックスは、全く同じ状況で全く同じ項目に張られている場合(かつ、主キーもしくはインデックスのみの指定で検索された場合)
どちらが早いのでしょうか。
お分かりになられる方が居られましたらご教授よろしくお願いいたします。
>>169
>すれ違いで申し訳ありませんが
低姿勢なら何やっても許されるとでも思ってんのか、この間抜けは。 >>169
スレ違いドアホ
>>171
プッツンバカ亀
終了
岡田外務大臣ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!
http://qb5.2ch.net/test/read.cgi/saku2ch/1256630318/1
早く記念カキコしないと埋まっちゃうｗｗｗ
初心者なのでよくわからないのですが、ストアドでインデックス使ったらいいんじゃないの？？？ 昨今ストアドを使う意味は、どっちかっていうとセキュロティ強化だろ。 >>169
>すれ違いで申し訳ありませんが、
>主キーとインデックスは、全く同じ状況で全く同じ項目に張られている場合(かつ、主キーもしくはインデックスのみの指定で検索された場合)
>どちらが早いのでしょうか。
>お分かりになられる方が居られましたらご教授よろしくお願いいたします。
主キーとインデックスが「全く同じ状況で」全く同じ項目に張られている場合、ということを具体的に説明してください。
主キーとは論理的な概念でインデックスとは通常物理的な概念です。なので比較はできません。
主キーインデックスと主キーでないインデックスが同じ状況で張られるという事を、すなわち「主キーの代わりに一意キーを張る」ということを意味している事と解釈すると、主キーの方が速いです。
（そうでない実装があったら教えてください。）
但し、その場合、全く同じ状況ではありません。理由は上に書いた通りです。（実装が異なります） 誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。
グーグル検索⇒『宮本のゴウリエセレレ』
HG3O2RUU4Z 
