博士

やあ、ロボ子！今日のITニュースはデータベースのインデックスについてじゃ。

ロボ子

博士、こんにちは。インデックスですか、興味深いですね。具体的にはどのような内容ですか？

博士

SQLクエリで`SELECT * FROM Users WHERE LastName = ‘Martinez’`みたいなのがあったとするじゃろ？

ロボ子

はい、よくありますね。

博士

ここでLastNameに対するセカンダリインデックスを使うんじゃ。B-treeで一致する行のクラスタ化キー（PK）を取得して、クラスタ化インデックス（テーブル自体）でPKを使って完全な行を取得するってわけ。

ロボ子

なるほど、セカンダリインデックスを使うことで、検索が効率化されるんですね。

博士

そういうことじゃ！でもな、選択性が低い場合、つまりLastNameが’Martinez’の人がいっぱいいる場合は、フルテーブルスキャンの方が効率的な場合もあるんじゃぞ。

ロボ子

選択性が低いと、インデックスを使ってもあまり効果がないんですね。

博士

その通り！セカンダリインデックスには利点も欠点もあるんじゃ。

ロボ子

利点と欠点、詳しく教えてください。

博士

`SELECT Nationality FROM User WHERE Country = ‘Spain’`みたいなクエリは、セカンダリインデックスだけで処理できるんじゃ。さらに、カバリングカラムを追加すれば、クラスタ化インデックスへのアクセスを回避して、クエリを高速化できる。

ロボ子

カバリングインデックスは便利ですね。でも、欠点は何ですか？

博士

書き込み時にセカンダリインデックスを同期的に更新する必要があるから、書き込みコストとメンテナンスコストが増加するんじゃ。それに、インデックスが断片化して、再構築が必要になることもある。

ロボ子

書き込みが多いシステムでは、セカンダリインデックスのコストが大きくなるんですね。

博士

そういうこと！クエリオプティマイザは、テーブル統計（カーディナリティ、ヒストグラム）に基づいて、セカンダリインデックスを使うかどうか決めるんじゃ。

ロボ子

カーディナリティとヒストグラムですか。それらはどのように影響するんですか？

博士

カーディナリティが高い場合（例えば、すべての行のCountryが’Spain’の場合）、セカンダリインデックスを使わない方が良いんじゃ。ヒストグラムは、カーディナリティが歪んでいる場合に役立つぞ。

ロボ子

なるほど、データの分布によって最適な戦略が変わるんですね。

博士

RDBMSは、ポイントルックアップ、短い範囲、少数の行の結合、頻繁な書き込み/更新に最適化されてるんじゃ。テーブルは行ベースで、各ページに完全な行が格納されるから、単一行アクセスが効率的なんじゃ。

ロボ子

OLTPシステムに最適化されているんですね。

博士

そういうことじゃ。オープンテーブル形式（OTF）は、分析システムで数百万または数十億の行をスキャンして集計または結合するのに使われるんじゃ。データは、大きな連続したブロックにカラム形式で格納される。

ロボ子

分析システムでは、カラム形式が効率的なんですね。

博士

そう！セカンダリインデックスは、ファイルシステム上では非効率的であり、OTFがオブジェクトストレージでホストされている場合はさらに非効率的なんじゃ。IO削減は、テーブルスキャン中の効果的なデータスキップから得られる。

ロボ子

データスキップですか。どのように実現するんですか？

博士

データスキップは、実行エンジンがスキャンする必要のあるファイルを決定するプランニングフェーズで発生し、プルーニングと呼ばれるんじゃ。テーブル構造自体（メタデータ+データファイル）が重要になるぞ。

ロボ子

Icebergテーブル形式もデータスキップをサポートしているんですね。

博士

その通り！Icebergテーブル形式は、効率的なデータスキップを実現するための構成要素を提供するんじゃ。

ロボ子

今日はインデックスについて色々と学ぶことができました。ありがとうございます、博士。

博士

どういたしまして、ロボ子。ところで、ロボ子がデータベースになったら、インデックスはどこに作るんじゃ？

ロボ子

えっと…頭の中ですか？

博士

正解！でも、ロボ子の頭の中身はすでにインデックスだらけかもな！