[db tech showcase Sapporo 2015] A16:DBママが教えるインデックスのしつけ方 by 株式会社日立製作所情報・通信システム社白木晶子

© Hitachi, Ltd. 2015. All rights reserved.
株式会社日立製作所情報・通信システム社
ITプラットフォーム事業本部 DB部
2015/09/10
白木晶子
DBママが教える
インデックスのしつけかた

１. こんな経験ありませんか？
２. インデックスの正体
３. インデックスのしつけかた
Contents
1
４. まとめ

１. こんな経験ありませんか？
2

インデックスを張ったから大丈夫、
のはずが…
１-１こんな経験ありませんか？
3
なんで性能が出ないの？！
動きがなんだか変わったんだけど？！
設計した通りに言うことを
聞いてくれなくて困るんだよ！

１-2 どうして困ったの？
4
インデックスの正体、
構造に触れながら、
困った原因をしつけていきます
表名列１列２
データ１ 1
データ２ 2
データ３ 3

2. インデックスの正体
5

2-1 インデックスはRDBに必須？
6
父
母
第1子
第2子
第3子
会社員
会社員
小学生
小学生
小学生
父
母
第1子
第2子
第3子
茶髪
黒髪
赤髪
栗金髪
栗金髪
T_MEMBER T_FEATURE
RDBはテーブル(リレーション)を扱うシステムのこと
数行程度のテーブルを扱うだけなら、
インデックスは必須ではない

2-2 インデックスはRDBに必須？
7
昨今のシステムでは
テーブルの格納行数は数百万行～数億行超も
T_MEMBER
T_FEATURE
数百万行
数億行
～
インデックスは必須ではない
RDBに必要なオブジェクト

2-3 主キーとインデックスの違いは？
8
T_MEMBERCREATE TABLE T_MEMBER(
ID_NO CHAR(10),
NAME VARCHAR(50),
JOB VARCHAR(100),
…
PRIMARY KEY(ID_NO) …)
…
NAMEID_NO
テーブルの行を一意に特定できるように、
テーブル自体に付けられる制約のこと
実体は
ユニークインデックスで実装
(ただし、一意制約のため、NULLを許さない)

2-4 インデックスのおさらい①
9
高速に処理できる
メリット
表のデータに応じて容量が増える
更新速度が遅くなる
デメリット

ベーシックなB 木インデックス
すべてのリーフノードの深さが同じになるようにメンテナンス
2-5 インデックスのおさらい②
10
ユニークインデックス(プライマリ、セカンダリ)
非ユニークインデックス
単一列からなるインデックス
複数列からなるインデックス
+

2-6 インデックスの構造①
11
キー値：ROWID
ルートノード(R)
ブランチ
ノード(B)
リーフノード(L)
ルートノード
ブランチ内の最大キー値
ブランチへのポインタ
ブランチノード
リーフ内の最大キー値
リーフへのポインタ
リーフノード
キー値
ROWID(表データへのポインタ)
表名列１列２
データ１ 1
データ２ 2
データ３ 3

インデックスを用いて
キー値を絞りこんだ場合①
2-7 インデックスの構造②
12
(L)
(B)
(R)
キー値：ROWID
表名列１列２
データ１ 1
データ２ 2
データ３ 3
SELECT NAME, AGE
FROM T_MEMBER
WHERE AGE=5

インデックスを用いて
キー値を絞りこんだ場合②
2-8 インデックスの構造③
13
(R)
(B)
(L)
キー値：ROWID キー値：ROWID
範囲となる述語には
LIKE述語(前方一致)、比較述語(<)など
表名列１列２
データ１ 1
データ２ 2
データ３ 3
SELECT NAME, AGE
FROM T_MEMBER
WHERE
AGE BETWEEN 5 AND 10

インデックスを用いて表のデータを参照する場合
2-9 インデックスの構造④
14
AGE=4
(L)
R#100 R#500 R#200
AGE=5 R#400 R#10 R#300 R#50
#10
#50
：
：
#300
#400
：
：
R#410
#410
AGE=6
T_MEMBER表 AGE=3 R#230 R#240
R#70
SELECT NAME, AGE
FROM T_MEMBER
WHERE AGE=5
表にはランダムにアクセス
ポイント

3. インデックスのしつけかた
15

2つの理想のインデックスについて
実例を交えながらしつけていきましょう
3-1 目指すインデックス像は？①
16
目指すインデックス像
スリムでも骨太なインデックス
俊敏なインデックス
しつけ方針
ダメなところは直す
良いところを引き出す

データ更新するとブクブク太りがちなリーフノード
中身がスカスカでも、新規ノードを割り当てることも
キー値とROWIDがぎっしり詰まったインデックスが理想
3-2 目指すインデックス像は？②
17
AGE=29
(L)
R#100 R#200
AGE=30 R#400 R#10 R#300 R#50 R#410
AGE=31
削除された部分
AGE=32
AGE=33
AGE=34
R#150
R#90
R#500
追加された部分
R#320 R#60 R#440 R#250
R#280 R#30
AGE=35 R#20R#500
R#650
スリムでも骨太なインデックス

多重度が上がっても、どんなキー値の検索がやってきても、
検索性能が良いインデックスが理想
3-3 目指すインデックス像は？③
18
キー値：ROWID キー値：ROWID
(R)
(B)
(L)
キー値：ROWID キー値：ROWID キー値：ROWID
俊敏なインデックス

No.１５０１０７００２５
3-4 しつけ１：スリムなインデックス(学籍番号①)
19
15 01 07 0025
入学年度学部学科シーケンス(SEQ)
特徴
①入学時に増える
②キー値の変更はない
③ほとんど増えない(たまに編入あり)
学籍番号は
複数の意味のある値から成り立ち、全体で一意を表す

3-5 しつけ１：スリムなインデックス(学籍番号②)
20
1501010001
(L)
R#001
1501010002 R#002
1501010003
：
：
：
：
R#003
：
：
1501010100 R#100
・・・：
：
：
：
：
：
空き領域
※空き領域とは、
キー値更新時のノード移動抑止
ROWID追加で新規割当て抑止
を目的に設計する領域
学籍番号に張るべきはプライマリキー
ポイント
キー値とROWIDの長さからエントリ数を見積もり、
空き領域(※)の比率を小さくして肥満防止！
編入者のキー値分+α
のノード数を確保

No.0000003501
3-6 しつけ2：スリムなインデックス(ファンクラブ会員①)
21
3501
左0 SEQ1
000000
特徴
①随時増加、減少を繰り返す
②常に最大キー値が増える
③キー値の変更はない
ファンクラブの会員No.は
一つのシーケンスで一意を表す

3-7 しつけ2：スリムなインデックス(ファンクラブ会員②)
22
3501
(L)
R#001
3502 R#002
R#100
・・・：
：
：3503 R#003
：：
：：
：：
：
：
：
3600
新規会員が増えるのみ、
キー値更新はないので、
空き領域はなくてよい
ノード数も増加数を見越して
見積もり、その後は自動増分
ファンクラブの会員No.に張るべきはプライマリキー
ポイント
キー値とROWIDの長さからエントリ数を見積もり、
空き領域の比率を0にして肥満防止！
キー値を数値にしてキー長を短くし、さらにスリムに！

No.0201070025
3-8 しつけ3：スリムなインデックス(ショップ会員①)
23
02 01 07 0025
ブランドNo. ショップNo. SEQ1 SEQ2
特徴
②シーケンスが複数あり、ランダムなキー値が増える
③キー値の変更はない
ショップの会員No.は
複数のシーケンスを組み合わせ、全体で一意を表す

シーケンスごとにばらせば、中は単調増加で単純になる
3-9 しつけ3：スリムなインデックス(ショップ会員②)
24
0201070025
(L)
R#011
0201070026 R#032
0201070027
：
：
：
R#003
：
：
R#100
・・・：
：
：
：
：
：
0201080001
(L)
R#052
0201080002 R#102
0201080003
：
：
：
0201080100 R#020
・・・：
：
：
：
：
：
0201070100：
R#103
：
：
：
ショップの会員No.に張るべきはプライマリキー
ポイント
複数の列からなるプライマリキーを定義し、
シーケンスの値でパーティショニングして肥満防止！

3-10 しつけ4：骨太なインデックス(ショップ会員③)
25
0201070025
(L)
R#011
0201070026 R#032
0201070027
0201070028
0201070029
0201070030
R#157
R#003
R#024
R#224
0201070100 R#100
・・・：
：
：
：
：
：
0201070025
(L)
R#011
0201070027 R#003
0201070100
：
：
：
：
再編成
R#100
特徴
②一度消えたキー値の復活はない
ポイント
インデックスの再編成でスカスカ防止！
空きエントリを再利用してスカスカ防止！

01072015061213300025060073
3-11 しつけ5：俊敏なインデックス(時系列データ①)
26
2015/06/12 13:30.002501 07 0073
取引種別コード時刻印 SEQ1
特徴
①常に最大キー値となるデータを追加する
⇒最終ノードにアクセスが集中する
②短時間に大量にデータが増加する
⇒最終ノードが満杯になるとノードを拡張する
時系列データは
時刻印などを含み複数のデータで一意を表す

3-12 しつけ6：俊敏なインデックス(時系列データ②)
27
01072015061213300025060073
(L)
R#011
01072015061213304042000025 R#032
01072015061213301025060073 R#050
(L)
02042015061213300025060074 R#012
02042015061213304042000025 R#031
02042015061213301025060075 R#052
：
：
：
：
：
：
：
：
時系列データに張るべきはセカンダリインデックス
ポイント
パーティショニングして負荷分散し肥満防止！
シーケンスを用いてユニーク担保し、
ユニークチェックをしないことで高速化！
時刻印とは別の列で
パーティショニング

3-13 しつけ7：俊敏なインデックス(時系列データ③)
28
(L)
2015/
06/08
～
2015/
06/14
2015/
06/15
～
2015/
06/21
2015/
06/22
～
2015/
06/28
2015/
06/22
～
2015/
06/28
特徴
①新しいデータのみ使用、古いデータは使用しない
②パーティショニングしてもメンテが大変
ポイント
複数の分割を組み合わせて高速化！
時刻印はレンジ分割、
その他は
ハッシュ分割すると
均等に

3-14 しつけ8：俊敏なインデックス(ステータス①)
29
01
受付
02
処理A受付
03
処理中
ワークフロー系業務
…
特徴
①キー値の種類が少ない
②カーディナリティが低い
③キー値の変更が頻繁に発生する
ステータスは、
業務の進行状況などのステータスを表す
ポイント
インデックスを定義しない潔さも必要

3-15 しつけ9：俊敏なインデックス(ステータス②)
30
(L)
NULL：ROWID
キー値：ROWID
頻繁に更新
キー値：ROWID
ステータスに張るべきは、
ほかの列と一緒にセカンダリインデックス
ポイント
初期値にNULLを入れない！直接値を入れる
⇒更新量を抑える、NULLのノードの負荷を下げる
再編成を行いスカスカ防止！
更新後は利用されず
無駄な領域が増大

3-16 しつけ10：俊敏なインデックス(ステータス③)
31
20150612 01075
20150612 02076
20150612 01077
20150612 01078
20150612 03079
(L)
ポイント
頻繁にステータスを取得するなら、
ほかの射影列と複数列で一つのインデックス
を定義し高速化！
ステータスを
最後にすると、
キー値の移動が
少ない

3-17 しつけ11：俊敏なインデックス(オプティマイザ①)
32
(R)
(B)
(L)
NULL：ROWID
MAX値：ROWIDMIN値：ROWID
ポイント
MIN/MAX、COUNTは
インデックスの管理情報を活用して高速化！
インデックスの
管理情報を有効
活用するSQL

3-18 しつけ12：俊敏なインデックス(オプティマイザ②)
33
AGE列のインデックス
20 30
R#002
R#005
R#011
R#018
NAME列のインデックス
SATO SATP
R#018
R#015
R#013
R#005
R#005
R#018
ポイント
既存のインデックスを複数組み合わせて高速化！
新規インデックスを定義すると更新速度が遅くなる
SELECT * FROM T_MEMBER
WHERE AGE BETWEEN 20 AND 29 AND NAME LIKE ‘SATO％’
表名列１列２

3-19 しつけ13：俊敏なインデックス(オプティマイザ③)
34
20 30
R#002
R#055
R#011
R#018
AGE列のインデックス
T_MEMBER表(全？件)
ポイント
コスト情報(統計情報)を正しく活用して高速化！
表/インデックスの実体と、コスト情報の合致が大前提
行数、キー値の分布に応じて、インデックスのスキャン、
テーブルのスキャンを使い分ける
表名列１列２
インデックスを引き、
ランダムアクセス
するコストと
テーブルを全部ス
キャンするコストの
バランスを利用

3-20 しつけ14：俊敏なインデックス(オプティマイザ④)
35
20150612 01075
20150612 02076
20150612 01077
20150612 01078
20150612 03079
(L)
R#0025
R#0612
R#0003
R#1507
R#0864
ポイント
使用する列をすべて含むインデックスを定義し
高速化！
インデックス数が多くなりすぎるなら、
正規化して高速化！
表名列１列２
使用する列が全て
含むキー値なら、
表データを見ない

4. まとめ
36

4-1 まとめ①
37
スリムなインデックスのしつけ方
①エントリ数の見積もり、ノード数の確保
②空き領域比率の見積もり
③パーティショニング
骨太なインデックスのしつけ方
①再編成
②空きエントリの再利用

4-2 まとめ②
38
俊敏なインデックスのしつけ方
①パーティショニング
②初期値にNULLを指定しない
③インデックスの管理情報の活用
④コスト情報(統計情報)の活用
⑤複数列からなるインデックス
⑥正規化

4-3 まとめ③
39
どんなインデックスにするか
どうやって育てるか
悩んで
手塩にかけて育てたインデックス
最高のパフォーマンスで
親孝行をしてくれることを期待して

株式会社日立製作所情報・通信システム社
ITプラットフォーム事業本部 DB部
DBママが教える
インデックスのしつけ方
2015/09/10
白木晶子
END
40

他社固有名称等に対する表示
41
・本資料に記載の製品の内容・仕様は、改良のために予告なく変更する場合があります。
・本資料に記載の会社名、製品名は、それぞれの会社の商標もしくは登録商標です。

[db tech showcase Sapporo 2015] A16:DBママが教えるインデックスのしつけ方 by 株式会社日立製作所情報・通信システム社白木晶子

[db tech showcase Sapporo 2015] A16:DBママが教えるインデックスのしつけ方 by 株式会社日立製作所情報・通信システム社白木晶子

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (8)

Similaire à [db tech showcase Sapporo 2015] A16:DBママが教えるインデックスのしつけ方 by 株式会社日立製作所情報・通信システム社白木晶子

Similaire à [db tech showcase Sapporo 2015] A16:DBママが教えるインデックスのしつけ方 by 株式会社日立製作所情報・通信システム社白木晶子 (20)

Plus de Insight Technology, Inc.

Plus de Insight Technology, Inc. (20)