インデックスはどこに貼るべきか？

**NAME IS NULL** · 2006/06/20(火) 11:28:32

無知な私に教えてくださいm(_ _)m
Where文でよく使う項目にインデックスを貼っていたのですが
ググったりして探してみるとどうも違うようですが、みんな曖昧な言いまわしで
よくわかりません。
たとえば、PostgreSQLで以下のようなテーブルがあるとします。
---------------------------
SNO　　　　　　　　　　NUMERIC(8) [PRIMARY KEY]
NAME　　　　　　　　　VARCHAR(100)
SEX　　　　　　　　　　 NUMERIC(1) -- 0:男、1:女
---------------------------
SNOは通し番号でPRIMARY KEYなのでインデックスが貼られますが
クエリー発行時に「where SEX = 1 」とよく利用する場合にSEXにはインデックスを
貼るべきなのか貼らないべきなのかが分かりません。

1 · 2006/06/20(火) 11:31:40

試しに二つのテーブルを用意して実験してみました。
--テーブル1
create table test1(
sno serial not null,
name varchar(100),
sex numeric(2),
primary key(sno)
);

--テーブル２
create table test2(
sno serial not null,
name varchar(100),
sex numeric(2),
primary key(sno)
);

create index test2_indexA1
on test2
(sex);

この二つのテーブルにまったく同じデータを１０個ほど入れて
・explain select * from test1 where sex = 1 ;
・explain select * from test2 where sex = 1 ;
を実行してみました。

test1のほうは
Seq Scan on test1 (cost=0.00..22.50 rows=5 width=183)
Filter: (sex = 1::numeric)
という結果でした。

test2のほうは
Index Scan using test2_indexa1 on test2 (cost=0.00..17.07 rows=5 width=183)
Index Cond: (sex = 1::numeric)
という結果でした。

データ数も少ないのでコストはあまり変わりませんがusing indexと出てるのでtest2のほうが
インデックスが使われています。ということはやはりよく検索する項目にはインデックスを張るべきなのでしょうか？？

**NAME IS NULL** · 2006/06/20(火) 12:19:13

　　(　ﾟдﾟ)
＿(__つ/￣￣￣/＿
　　＼/　　　　/

　　　　_, ._
　　（　ﾟ Дﾟ）
＿(__つ/￣￣￣/＿
　　＼/　　　　/

　(　ﾟдﾟ)
＿(__つ/￣￣￣/＿
　　＼/　　　　/

　　　　_, ._
　　（；ﾟ Дﾟ）
＿(__つ/￣￣￣/＿
　　＼/　　　　/

　　(ﾟдﾟ　)
＿(__つ/￣￣￣/＿
　　＼/　　　　/

　(дﾟ　)
＿(__つ/￣￣￣/＿
　　＼/　　　　/

**NAME IS NULL** · 2006/06/20(火) 12:53:47

判らなきゃ聞かずに勉強しろ。
このあたりはSQL知ってるレベルから、DB使えるってレベルへの大事な部分だ。

U ◆CZtFsGiu0c · 2006/06/20(火) 16:23:53

Postgresってコストベースでしょ?
たかだかデータ10件でインデックススキャンを選択するオプティマイザ
って信用できるのだろうか。

それはともかく、

>クエリー発行時に「where SEX = 1 」とよく利用する場合にSEXにはインデックスを
貼るべきなのか貼らないべきなのかが分かりません。

SEXって男性、女性(+NULL?)しかないわけでしょ? そのフィールドに
インデックス貼って本当に効率がどこまで上がるのかな? それから、
>>4も書いているとおりそんな単純な問題ではないから、基礎から
勉強しましょう。
＃まあプランを検証しているだけマシか…

**NAME IS NULL** · 2006/06/21(水) 15:20:04

いや、単発質問スレ立ててる時点で勉強しても許しがたい

**NAME IS NULL** · 2006/06/22(木) 09:36:01

お尻に張ってください

**NAME IS NULL** · 2006/06/22(木) 13:05:59

尻でもSEXでもいいが、張って高速化できるんなら張れば。
ちなみにDBMSやindexの種類にもよるが、値の分布が少ない場合はあんまり効果無いぞ。
場合によっちゃ、張っても全スキャンの方が速いと判断して使ってくれない場合もある。

**NAME IS NULL** · 2006/06/22(木) 17:17:28

昔は、使ってくれないだけならまだしも、使った上に全件より遅くなったりしたもんだ。
今でもそういうDBMSあるだろね。

**NAME IS NULL** · 2006/06/25(日) 16:34:46

SEXの値のデータ分布が 1 対 1 なら、あまり意味が無い
男(0)：女(1)=9：1なんかで SEX = 1 という検索を行う必要があれば、インデックスを張る価値があるよ
この場合、SEX = 0 の検索では効果はないけどね

と経験上の話を書いたけど、残念ながら Oracle(たしか8iくらい？) は SEX = 1 のような検索でも
インデックスは使ってくれなかった。
入力された検索条件をユーザープログラム側で解析して、SEX = 1 となるような
検索になるときは、ヒントでインデックスを使うように指示した記憶がある。
ある特殊な検索だったんだけど、結果を出すのに数十秒かかってた処理が
一瞬で返るようになってビックリした。

結局、その検索条件でデータをガッツリ絞り込めることが保証されるなら
インデックスを張るべきだね。

**NAME IS NULL** · 2006/06/25(日) 16:43:07

まぁ、列のカーディナリティが低いなら、ビットマップインデックスはるか、
パーティションテーブル使った方がいいかもな

**NAME IS NULL** · 2006/06/25(日) 20:11:03

男と女のデータの数が1:1でも
インデックスを使うとデータは半分になるわけだが。

**NAME IS NULL** · 2006/06/26(月) 00:26:19

>>12
ほぅ・・・
100万件登録されているテーブルで50万件をインデックスにより特定して全スキャンさせるのか？
データ分布が1対1で、レコードをある程度絞り込めるならインデックスを使う必要はないだろ。

>>10の考え方は、インデックスをインデックスらしく使うのではなく
インデックスを介して、そのノードが保持するテーブル内に散乱したレコードの
行番号リストを得ることを目的としてるんだが。

**NAME IS NULL** · 2006/07/01(土) 23:02:23

カーディナリティが低い場合はインデックスを忘れろ。

**NAME IS NULL** · 2006/07/06(木) 10:21:52

> 100万件登録されているテーブルで50万件をインデックスにより特定して全スキャンさせるのか？
100万件全スキャンさせるのよりも、50万件全スキャンさせるほうが
半分ですむ。

**NAME IS NULL** · 2006/07/06(木) 12:56:01

>>15
インデックスたぐるコストのほうが、べた舐めよりかかる。

**NAME IS NULL** · 2006/07/06(木) 16:47:53

多くの場合、インデックスは昇順でならんでいる。
だから最初と最後の位置を特定すれば、あとは舐めるだけと変わらない。
データが少ない場合は、最初と最後の位置を特定するコストに相殺されるが、
データが多くなると、スキャンする範囲が狭くなるので有効。

**NAME IS NULL** · 2006/07/06(木) 22:59:18

それはindexのリーフに必要なデータが揃っている場合だけな。

select SEX from TABLE where SEX=1

**NAME IS NULL** · 2006/07/07(金) 09:08:47

だーね、SQL鯖でいうクラスタ化インデックスって場合。

**NAME IS NULL** · 2006/07/09(日) 16:29:41

せめて column 名は GENDER にしないか。

**NAME IS NULL** · 2006/07/09(日) 20:28:12

>>20
甘いな・・・
若手女プログラマに列名を言わせるのが楽しいんだろ
顔真っ赤にして言われると、こっちも苦笑いするしか無いがな

30過ぎの負け犬だと躊躇することなく列名を発するからツマラン

1 · 2006/07/25(火) 16:04:37

皆さん！レスありがとうございます。
B-TREEの基礎から勉強してきました。インデックスとは何かが良くわかりました。
奥が深くて回答しづらいのも良くわかりました。こんなスレたててすみませんでした。

**NAME IS NULL** · 2007/01/27(土) 07:42:17

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

**NAME IS NULL** · 2007/01/27(土) 10:46:22

>>22
んでどういう見解に至ったか説明せい。
カーディナリティという言葉を含めて。

**NAME IS NULL** · 2007/02/01(木) 12:23:54

なにげに良スレ化。

**NAME IS NULL** · 2007/02/12(月) 12:58:20

ほしゅ

**NAME IS NULL** · 2007/02/14(水) 09:39:15

インサートとかセックスとか、童貞にはハァハァ対象だな。

**NAME IS NULL** · 2008/10/30(木) 11:31:29

インデックスたん(;´Д｀)ﾊｧﾊｧ

**NAME IS NULL** · 2008/11/11(火) 22:48:21

>>25
できるよ。
以上。
はい次の方。

**NAME IS NULL** · 2009/04/06(月) 09:50:39

ソートで使う列（値はバラバラ）に
インデックスは効果ありますか？

**NAME IS NULL** · 2009/04/11(土) 20:01:58

>>30
意味はあるよ。
でもバラバラにインデックスを定義するよりも、複合インデックスにした方が効果的なのは言うまでもない。

**NAME IS NULL** · 2009/04/11(土) 20:10:45

>>10
Oracle8iのオプティマイザは糞だからな。
統計情報を採取した後に、急激にパフォーマンスが悪くなるなんてこともあった。
現在のバージョンのオプティマイザは優秀になったが。

Oracle10gや11gは、カーディナリティが低いSEXのインデックスでも使用してくれるだろう。
だが1つだけ注意しないといけないことがあってな。
それはSEXの抽出条件にバインド変数を使用してしまうと、
女で抽出する場合と男で抽出する場合でも、同じ実行計画を組み立ててしまうということ。

だから、ｵﾏｲの案のようなそういう特殊条件をやる場合は、
SEXの抽出条件にバインド変数を利用しないようにしないと問題が発生するだろう。

**NAME IS NULL** · 2009/04/11(土) 20:13:26

やべ、3年前のレスに返信してしもうたわｗ
ﾊｽﾞｶｼｰ　（/ω＼）

**NAME IS NULL** · 2009/04/13(月) 13:05:07

　ｘ‐‐―…―‐--ｘ
人人　　　　　　　　＼
　　（ｰ:‐:‐:‐:‐:‐:‐:‐:i　ヽ
　マ（＿＿＿＿_____!　 !
　ジ（ﾉへﾊﾉﾊﾉィi::i::ﾊ　!
　で（ｒ心｀　ｒ心ﾍ::l::!｜
　っ（弋ｿ　　弋ｿ}ﾉ::N.｜
　!? （:::ｰ''／＼ｰ'::Y:::|　て
::ﾊ⌒i u　＼／　 .ｲ:|:|　　(
｀ヽ::i:|＼｀　　７{ ﾉ:|::!:!　|

**NAME IS NULL** · 2009/06/17(水) 23:31:00

ビットマップはテーブルの目的によっちゃ使わないほうが良い事もある。

トランザクション系なら避けたほうがいい。

おいらは本番で痛い目を見た......

**NAME IS NULL** · 2009/08/27(木) 00:10:55

MySQL5.x系を使っているのですが、どうも件数が遅くなりそうで心配です。

簡単に言うと、名簿を作っているのですが、
'部'　'課'　'係'　というカラムで個人情報があって、それに対して、

( 部１ = 部２　and 課１ = null and 係１＝ null ) or
( 部１ = 部２　and 課１ = 課２ and 係１＝ null ) or
( 部１ = 部２　and 課１ = 課２ and 係１＝課２l ) or

というマッチングを頻繁にやってます。

この場合、部、課、係の複合インデックスのほかに、部、課、係それぞれの
インデックスを作ることは効果あるでしょうか？

**NAME IS NULL** · 2009/08/27(木) 14:28:08

エンジンによっても違うらしいから
explainしてみるか実測してみたら？

**NAME IS NULL** · 2009/08/27(木) 20:54:57

やっぱり個別インデックスをつけた方が速かったです。
エンジンは、ISAMを使っています。

更新時に重くなければ、このままインデックスをつけて
やってみます。混雑時じゃないと実測できないけど・・・。

**NAME IS NULL** · 2009/12/01(火) 01:36:35

　　　　　　　　　　　　　 _..　-――-　._
　　　　　　　　　　　 .／ ,―――‐-　.._` .、
　　　　　　 x　　　/　 ./　／　／　　｀`＼.　＋
　　　　　　　　　 /_.. ィ7T.ﾌ厂￣｀ﾌｉ ‐-　._ |〉　　 x
　　　　　 .x　　 !　￣ﾌ/l/_×／/　|ﾊハl　.ﾄ、　 x
　　　　|! /　　　|　　／|,ｲ._T_i`　　.r≦lハ!|｀`　　　+
　　　　ll/_ 　　 .|　　|　|'弋..!ﾉ　　 i'＋!ｌ　|
　　　/ ミr`! 　 /　　 l　|' ' '　 ,‐- ..__ﾞｰ' .!l .|
　　　ﾄ､ｿ　.!　./　　 .,!l .ﾄ､　　ｌ　　｀,! 　 .ハ.!　
　　　/ll＼｀テヽ、 /_,| |l: ＞ .ヽ.. ィ＜l 　 l|
　　./' l|/l. >'　/ /＼. | | ＼＼ｰ'/ ./ ,,;:`:;'ﾞ"r;:ﾞc
　　'　 l|l l/　./ /　　 | | 　_＼_×_/.ｨ'...二二二l ヽ
　　　　 | ヽ./ /　　　/|.|i彡_　　　　　　　　　　　＼＼
　　　　 | ／／　 .／ .l|| ´　￣,｢￣｢ｌi￣二ﾆ -'´ ヽ.
　　　　└――'"l/／ .|! 　 / / ! .|　|' |l ／/
　　　　　　　　　/　＿_l＿/_/__.|__|__l_`_ｰ_'＿＿＿__.／

**南沢木綿子** ◆qdIdLOElrVy2 · 2010/09/08(水) 10:12:20

　　∧,,,∧　
　( 　・∀・)　ほー　それで
　 (　　：　)　
　　し─J

【38.6m】 **電脳プリオン** · 2012/05/26(土) 14:48:22.22

>>40

最近このコテよく見かける

**NAME IS NULL** · 2013/06/12(水) 19:30:30.22

お！今話題のスレタイ！

**NAME IS NULL** · 2013/06/21(金) 18:05:24.95

最初か最後のページだな。

**NAME IS NULL** · 2013/08/11(日) NY:AN:NY.AN

痛いとこにでも貼っとけば良いんでない？

**NAME IS NULL** · 2015/01/03(土) 03:54:34.12

第1章　赤・緑・青編　　　　　　　　　　　　　1巻～3巻
第2章　イエロー編　　　　　　　　　　　　　4巻～7巻
第3章　金・銀・クリスタル編　　　　　　　　8巻～15巻
第4章　ルビー・サファイア編　　　　　　　15巻～22巻
第5章　ファイアレッド・リーフグリーン編　22巻～26巻
第6章　エメラルド編　　　　　　　　　　　　26巻～29巻
第7章　ダイヤモンド・パール編　　　　　　30巻～38巻
第8章　プラチナ編　　　　　　　　　　　　　38巻～40巻
第9章　ハートゴールド・ソウルシルバー編　41巻～43巻
第10章　ブラック・ホワイト編　　　　　　　　43巻～51巻
第11章　ブラック２・ホワイト２編　　　　　　　52巻～
第12章　エックス・ワイ編　　　　　　　　　　　 XY編2巻～

**NAME IS NULL** · 2015/01/23(金) 00:48:08.85

腰

◆cqxclbaQk/hG · 2015/02/01(日) 15:23:39.19

最初に無があった
無から有が生まれた
これが全ての真理

**NAME IS NULL** · 2015/02/01(日) 16:41:47.17

あそこ。

**NAME IS NULL** · 2015/02/10(火) 00:16:06.77

http://jbbs.shitaraba.net/sports/42269/

**NAME IS NULL** · 2015/09/19(土) 02:46:04.98

>>1
インデックスは作るもの。

**ギンコ** ◆BonGinkoCc · 2015/12/14(月) 20:18:32.99

インデックスは、DATで言うと、スタートID、DVDやBDでいうとチャプターに該当する。

スタートIDやチャプターを任意の場所に振っておくと、録音後や録画後に後から簡単に探し出せますよね。
インデックスを降っていないファイルの場合は、シーケンシャルアクセスを行い、目的のデータが見つかるまで
順番にたどり着くしか方法が無い。

**NAME IS NULL** · 2015/12/14(月) 23:00:31.65

>>51
かなり違うが？

**NAME IS NULL** · 2017/12/29(金) 12:04:37.50

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

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

95548V17E0

**NAME IS NULL** · 2023/01/21(土) 15:48:31.36

規制解除されてる

**NAME IS NULL** · 2023/07/08(土) 18:50:29.35

( ＇∇＇)y-｡ο ○ ｱﾊﾊﾊﾊ