インデックスに関して
作成日時:2024-09-22
更新日時:2024-09-22
クラスタ化インデックス
インデックス上に実データが格納されているもの。
MySQLのInnoDBなど。
カバリングインデックス
- 取得したい内容が全てインデックスに含まれるインデックス
- 実データを参照しに行かなくて済むので、パフォーマンスが上がる。
- 非クラスタ化インデックスや、MySQLにおけるセカンダリインデックスで効果を発揮する
付加列インデックス
インデックスキーの列に加えて、非キー列(付加列)をインデックスに含める機能。
key => PK + 追加情報。
効果的にカバリングインデックスを作成できる。
部分インデックス
部分インデックス
特定のカラムにのみ、インデックスを貼る。
CREATE INDEX idx_active_users ON users (username)
WHERE is_active = true;
SELECT username
FROM users
WHERE is_active = true AND username LIKE 'A%';
メリット
- インデックスサイズの削減
- 特定のクエリパターンのパフォーマンス向上
- ストレージ使用量の最適化
各RDBMSの対応
- PostgreSQL:広範なサポート
- MySQL:特定の構文はないが、関数ベースインデックスで類似の機能を実現可能
- SQL Server:フィルター付きインデックスとして実装
インビジブルインデックス
MySQL :: MySQL 8.0 リファレンスマニュアル :: 8.3.12 不可視のインデックス
- 使わないようにするだけ
- 実際には消されない
- 削除・再作成に時間がかかるから消すだけ
- パフォーマンス検証の時に使用したりする。ON/OFFでどう変わるかとか。
PostgreSQLには(いまのところ)無い。
アダプティブハッシュインデックス
MySQLのinnoDBなどのクラスタ化インデックスにおける。
セカンダリインデックスを使用して検索をする場合、
- セカンダリインデックスを使用し、PKを取得
- プライマリインデックスを使用し、データを取得
と、2段階アクセスが発生し、パフォーマンスがよくない。
この主キー検索を高速化するためにアダプティブハッシュインデックスがある。
イメージとしてはkeyがセカンダリインデックスの検索値のハッシュ、valueがレコードへのポインタ。
ハッシュなので等価検索のときにのみ使われる。
バッファプール上に作られる。
GROUP BY におけるインデックススキャン
{GROUP BY指定カラム, 集計対象値}
でインデックスを貼っているとした時、下記のスキャンが行われる。
タイトインデックススキャン
インデックスを使用してGROUP BYクエリを解決
ルースインデックススキャン
集計対象値のMINやMAXならば、各GROUP BY指定カラムの先頭のインデックスデータを見ればすぐわかる。
(A, 1),(A, 2),(A, 3),(B, 4),(B, 5)
ならば先頭のカラムの値、つまり1と4のカラムだけを見ればいいから
パフォーマンスはよい。
MIN()を取ろうとすれば、A1,B4が返却される。