- PR -

Indexをつけるポイントについて

1
投稿者投稿内容
きのこ
ぬし
会議室デビュー日: 2004/09/01
投稿数: 256
投稿日時: 2006-11-29 05:55
現在、データベースにデータウェアハウスのようなものをSQL2005に構築しましたが、
パフォーマンス（主にＳＥＬＥＣＴ文）を
あげるためＩＮＤＥＸをつけるかどうかを検討してます。
あるＤＢの管理者によるとレコード数で１０万をこえるレベルで初めて検討すると
いってました。
でも当然、アプリケーションで
その１０万を超えるテーブルとＪＯＩＮするテーブルに対しても、たとえそのレコード数が数百でもＩＮＤＥＸをつけたほうがいいのでしょうか？

たとえば
ＣＯＬＵＭＮ　Ｃ１、Ａ２，Ａ３、Ａ４、Ａ５
の５０万レコードあるテーブルTable-A
と
ＣＯＬＵＭＮ　Ｃ１，Ｂ２，Ｂ３、Ｂ４，Ｂ５
のレコード数が
５００程度のテーブル Table-B
に対して
update table-A
set A2=B2, A3='Y' where table-A.C1=table-B.C1
といったクエリーや

select A.*, B.B4, B.B5
from table-A as A, table-B as B
where A.C1=B.C1

といったクエリーが頻繁に実行されることが予想された場合、
Table-A, Table-BともＩＮＤＥＸをして
キーとして
たとえば、Table-Aでは
C1, A2, A3のといった順でコードとなるものに対して
ＩＮＤＥＸしていき
たとえば、Table-Bでもたとえ数が少なくても
C1, B4, B5のといった順でコードとなるものに対して
INDEXをつけたほうがパフォーマンス上、いいのでしょうか？

テーブルに対するIndexの有無をつける判断と
よく実行されるＳＱＬからＩＮＤＥＸのつけかたの定型的なやりかたなどが
ありましたら
アドバイスをいただければ幸いです


るぱん
ぬし
会議室デビュー日: 2003/08/01
投稿数: 1370
投稿日時: 2006-11-29 09:48
るぱんです。

引用:

よく実行されるＳＱＬからＩＮＤＥＸのつけかたの定型的なやりかたなどが
ありましたら
アドバイスをいただければ幸いです

教科書だそうで。
ここの４章に書いてある。

つなぐ相手には必要ないと思う。
その表に対して１０〜１５％ぐらいのデータをマッチングするのに
使うものだと思っています。

インデックスを張るとリソースが消費されます。
それが性能劣化につながる可能性も有るので。

それにインデックスの作業って、
設計時には雛形が終わっていて、
開発のSQLが固まった時点で完全に完了するものだと思います。

パフォーマンスって、後からあげるもんでなくて、
基本的に設計で考慮しておくものですよ。
設計で考慮したほうが、圧倒的にパフォーマンスは出ますよ。

[ メッセージ編集済み 編集者: るぱん 編集日時 2006-11-30 23:29 ]
1

スキルアップ／キャリアアップ（JOB@IT）