« WALを使わないテーブル | トップページ | 定期的なインデックス再作成を自動化 »

2014.04.04

インデックスの再構築タイミング(Informix)

インデックスもデータ集合である以上、RDBMSにおいてテーブルそのものと同様「荒れてくる」ものである。
これは不要となったページの残存や、データの入り繰りによるインデックスファイルの断片化といった物理状態として発生する。

PostgreSQLにおいてはそれはインデックス領域の増大、という形で目に見える形となり、Informixであればそれはインデックスレベルの増加という形で現れてくる。

Informixの場合

SELECT idxname, levels, leaves
FROM sysindexes
WHERE owner = [owner_id]
ORDER BY levels DESC;

IndexのB-treeの大きさがこれで確認できる。
このLevelsが大きい値となると、ルートノードからの末端階層数が多くなっているということであり、純粋にサーチパスが長くなり検索性能が劣化している。

ウチの内規ではlevelsが4以上になったインデックスについては再構築を検討するように勧告している。
ただ、再構築も万能ではなく、データの偏りによっては何回再構築しようが深いレベルを獲得してしまうインデックスもある。

インデックス再構築前
Index_namelevelsleaves
idx_line01442098
idx_line02425311

上記のようなインデックスたちをDROP/CREATEしてみたところ、、、

インデックス再構築後
Index_namelevelsleaves
idx_line01442082
idx_line02425234

リーフノードはわずかに減少して、多少まとまりよくなったみたいだが、Level自体は変わらなかった(^^;
SELECT性能をテストしてみたが、有意の差は出ず、残念ながら万能な対処法ではないことがわかっただけとなってしまった。

荒れやすいテーブルの特徴は
-最初は小さかったテーブルでINSERTがたくさんされるもの(0件スタートの履歴ファイルなど)
-追加と削除を繰り返すようなテーブル
があるようである。

|

« WALを使わないテーブル | トップページ | 定期的なインデックス再作成を自動化 »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/2022/59397167

この記事へのトラックバック一覧です: インデックスの再構築タイミング(Informix):

« WALを使わないテーブル | トップページ | 定期的なインデックス再作成を自動化 »