5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

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

2 :1:2006/06/20(火) 11:31:40 ID:???
試しに二つのテーブルを用意して実験してみました。
--テーブル1
create table test1(
sno serial not null,
name varchar(100),
sex numeric(2),
primary key(sno)
);

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

create index test2_indexA1
on test2
(sex);

この二つのテーブルにまったく同じデータを10個ほど入れて
・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のほうが
インデックスが使われています。ということはやはりよく検索する項目にはインデックスを張るべきなのでしょうか??


3 :NAME IS NULL:2006/06/20(火) 12:19:13 ID:???

  ( ゚д゚)
_(__つ/ ̄ ̄ ̄/_
  \/    /

    _, ._
  ( ゚ Д゚)
_(__つ/ ̄ ̄ ̄/_
  \/    /


 ( ゚д゚)
_(__つ/ ̄ ̄ ̄/_
  \/    /

    _, ._
  (;゚ Д゚)
_(__つ/ ̄ ̄ ̄/_
  \/    /


  (゚д゚ )
_(__つ/ ̄ ̄ ̄/_
  \/    /


 (д゚ )
_(__つ/ ̄ ̄ ̄/_
  \/    /

4 :NAME IS NULL:2006/06/20(火) 12:53:47 ID:QOvjXAXI
判らなきゃ聞かずに勉強しろ。
このあたりはSQL知ってるレベルから、DB使えるってレベルへの大事な部分だ。

5 :U ◆CZtFsGiu0c :2006/06/20(火) 16:23:53 ID:???
Postgresってコストベースでしょ?
たかだかデータ10件でインデックススキャンを選択するオプティマイザ
って信用できるのだろうか。

それはともかく、

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

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

6 :NAME IS NULL:2006/06/21(水) 15:20:04 ID:???
いや、単発質問スレ立ててる時点で勉強しても許しがたい

7 :NAME IS NULL:2006/06/22(木) 09:36:01 ID:???
お尻に張ってください

8 :NAME IS NULL:2006/06/22(木) 13:05:59 ID:IC52MLFC
尻でもSEXでもいいが、張って高速化できるんなら張れば。
ちなみにDBMSやindexの種類にもよるが、値の分布が少ない場合はあんまり効果無いぞ。
場合によっちゃ、張っても全スキャンの方が速いと判断して使ってくれない場合もある。

9 :NAME IS NULL:2006/06/22(木) 17:17:28 ID:???
昔は、使ってくれないだけならまだしも、使った上に全件より遅くなったりしたもんだ。
今でもそういうDBMSあるだろね。

10 :NAME IS NULL:2006/06/25(日) 16:34:46 ID:xGXxj73z
SEXの値のデータ分布が 1 対 1 なら、あまり意味が無い
男(0):女(1)=9:1なんかで SEX = 1 という検索を行う必要があれば、インデックスを張る価値があるよ
この場合、SEX = 0 の検索では効果はないけどね

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

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

11 :NAME IS NULL:2006/06/25(日) 16:43:07 ID:???
まぁ、列のカーディナリティが低いなら、ビットマップインデックスはるか、
パーティションテーブル使った方がいいかもな

12 :NAME IS NULL:2006/06/25(日) 20:11:03 ID:???
男と女のデータの数が1:1でも
インデックスを使うとデータは半分になるわけだが。

13 :NAME IS NULL:2006/06/26(月) 00:26:19 ID:???
>>12
ほぅ・・・
100万件登録されているテーブルで50万件をインデックスにより特定して全スキャンさせるのか?
データ分布が1対1で、レコードをある程度絞り込めるならインデックスを使う必要はないだろ。

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

14 :NAME IS NULL:2006/07/01(土) 23:02:23 ID:???
カーディナリティが低い場合はインデックスを忘れろ。

15 :NAME IS NULL:2006/07/06(木) 10:21:52 ID:vCGruU6t
> 100万件登録されているテーブルで50万件をインデックスにより特定して全スキャンさせるのか?
100万件全スキャンさせるのよりも、50万件全スキャンさせるほうが
半分ですむ。

16 :NAME IS NULL:2006/07/06(木) 12:56:01 ID:4t2wzNRO
>>15
インデックスたぐるコストのほうが、べた舐めよりかかる。


17 :NAME IS NULL:2006/07/06(木) 16:47:53 ID:U1S8L1hg
多くの場合、インデックスは昇順でならんでいる。
だから最初と最後の位置を特定すれば、あとは舐めるだけと変わらない。
データが少ない場合は、最初と最後の位置を特定するコストに相殺されるが、
データが多くなると、スキャンする範囲が狭くなるので有効。


18 :NAME IS NULL:2006/07/06(木) 22:59:18 ID:???
それはindexのリーフに必要なデータが揃っている場合だけな。

select SEX from TABLE where SEX=1



19 :NAME IS NULL:2006/07/07(金) 09:08:47 ID:+t31RxJ2
だーね、SQL鯖でいうクラスタ化インデックスって場合。


20 :NAME IS NULL:2006/07/09(日) 16:29:41 ID:???
せめて column 名は GENDER にしないか。


21 :NAME IS NULL:2006/07/09(日) 20:28:12 ID:???
>>20
甘いな・・・
若手女プログラマに列名を言わせるのが楽しいんだろ
顔真っ赤にして言われると、こっちも苦笑いするしか無いがな

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

22 :1:2006/07/25(火) 16:04:37 ID:???
皆さん!レスありがとうございます。
B-TREEの基礎から勉強してきました。インデックスとは何かが良くわかりました。
奥が深くて回答しづらいのも良くわかりました。こんなスレたててすみませんでした。

23 :NAME IS NULL:2007/01/27(土) 07:42:17 ID:8mHye8uN
オカマの思う壺
ttp://megabbs.com/pickles/index.html

24 :NAME IS NULL:2007/01/27(土) 10:46:22 ID:O+RfWf9V
>>22
んでどういう見解に至ったか説明せい。
カーディナリティという言葉を含めて。

25 :NAME IS NULL:2007/02/01(木) 12:23:54 ID:???
なにげに良スレ化。

26 :NAME IS NULL:2007/02/12(月) 12:58:20 ID:/s74tiRC
ほしゅ

27 :NAME IS NULL:2007/02/14(水) 09:39:15 ID:???
インサートとかセックスとか、童貞にはハァハァ対象だな。

28 :NAME IS NULL:2008/10/30(木) 11:31:29 ID:???
インデックスたん(;´Д`)ハァハァ

29 :NAME IS NULL:2008/11/11(火) 22:48:21 ID:???
>>25
できるよ。
以上。
はい次の方。

30 :NAME IS NULL:2009/04/06(月) 09:50:39 ID:gtB4cOSs
ソートで使う列(値はバラバラ)に
インデックスは効果ありますか?

31 :NAME IS NULL:2009/04/11(土) 20:01:58 ID:691PehwU
>>30
意味はあるよ。
でもバラバラにインデックスを定義するよりも、複合インデックスにした方が効果的なのは言うまでもない。


32 :NAME IS NULL:2009/04/11(土) 20:10:45 ID:691PehwU
>>10
Oracle8iのオプティマイザは糞だからな。
統計情報を採取した後に、急激にパフォーマンスが悪くなるなんてこともあった。
現在のバージョンのオプティマイザは優秀になったが。

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

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


33 :NAME IS NULL:2009/04/11(土) 20:13:26 ID:691PehwU
やべ、3年前のレスに返信してしもうたわw
ハズカシー (/ω\)


34 :NAME IS NULL:2009/04/13(月) 13:05:07 ID:???
 x‐‐―…―‐--x
人人        \
   (ー:‐:‐:‐:‐:‐:‐:‐:i ヽ
 マ (_________!  !
 ジ (ノへハノハノィi::i::ハ !
 で (r心`   r心ヘ::l::!|
  っ(弋ソ  弋ソ}ノ::N.|
 !? (:::ー''/\ー'::Y:::|  て
::ハ⌒i u \/  .イ:|:|  (
`ヽ::i:|\`  7{ ノ:|::!:! |

35 :NAME IS NULL:2009/06/17(水) 23:31:00 ID:fu0ZnfDa
ビットマップはテーブルの目的によっちゃ使わないほうが良い事もある。

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

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


36 :NAME IS NULL:2009/08/27(木) 00:10:55 ID:vGxTqY7s
MySQL5.x系を使っているのですが、どうも件数が遅くなりそうで心配です。

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

( 部1 = 部2 and 課1 = null and 係1 = null ) or
( 部1 = 部2 and 課1 = 課2 and 係1 = null ) or
( 部1 = 部2 and 課1 = 課2 and 係1 = 課2l ) or

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

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



37 :NAME IS NULL:2009/08/27(木) 14:28:08 ID:???
エンジンによっても違うらしいから
explainしてみるか実測してみたら?

38 :NAME IS NULL:2009/08/27(木) 20:54:57 ID:???
やっぱり個別インデックスをつけた方が速かったです。
エンジンは、ISAMを使っています。

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

39 :NAME IS NULL:2009/12/01(火) 01:36:35 ID:???
              _.. -――- ._
            ./ ,―――‐- .._` .、
        x   /  ./  / /    ``\.  +
           /_.. ィ7T.フ厂 ̄`フi ‐- ._ |〉     x
       .x    !  ̄フ/l/_×// |ハハl .ト、  x
    |! /    |  /|,イ._T_i`   .r≦lハ!|``   +
    ll/_     .|  | |'弋..!ノ     i'+!l |
   / ミr`!   /   l |' ' '  ,‐- ..__゙ー' .!l .|
   ト、ソ .! ./   .,!l .ト、  l  `,!   .ハ.! 
   /ll\ `テヽ、 /_,| |l: > .ヽ.. ィ <l   l|
  ./' l|/l. >' / /\. | | \ \ー'/ ./ ,,;:`:;'゙"r;:゙c
  '  l|l l/ ./ /    | |  _\_×_/.ィ'...二二二l ヽ
     | ヽ./ /   /|.|i彡_           \\
     | //  ./ .l|| ´   ̄,「 ̄ 「 li ̄二ニ -'´ ヽ.
    └――'"l// .|!   / / ! .| |' |l //
         / __l_/_/__.|__|__l_`_ー_'_____./


12 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)