SQLのINDEX（インデックス）の説明として正しいものはどれか。

解説

インデックスは本の「索引」と同じ発想で、目的のデータがどこにあるかを素早く見つけるための仕組みです。検索（SELECT）が速くなる代わりに、INSERT・UPDATE・DELETEのたびにインデックスも更新する必要があるため、書き込みのコストは増加します。「万能に速くなる魔法」ではなく、トレードオフがある点が重要です。データ圧縮とは無関係ですし、PRIMARY KEYには多くのRDBMSで自動的にインデックスが作成されます。インデックスはなぜ速いのかインデックスがない場合、データベースはテーブルの全行を先頭から順番にスキャンします（フルテーブルスキャン）。100万行あれば100万行を確認するため、データ量に比例して遅くなります。インデックスを作成すると、多くのRDBMSではB-Tree（バランス木）というデータ構造が内部に構築されます。B-Treeでは目的の値まで木の分岐をたどるだけで到達できるため、100万行あっても数十回程度の比較で済みます。-- usersテーブルのemailカラムにインデックスを作成 CREATE INDEX idx_users_email ON users (email); -- このSELECTがフルスキャンではなくインデックス経由になる SELECT * FROM users WHERE email = 'test@example.com';インデックスを貼りすぎると何が起きるか初学者にありがちなのが「速くなるなら全カラムに貼ろう」という発想です。しかし実際には以下の問題が起きます。書き込みが遅くなる: 1行追加するたびに全インデックスを更新する必要があるディスク容量を消費する: インデックス自体がデータとして保存されるため、テーブル本体と同程度の容量を使うこともある基本方針は「WHERE句やJOINで頻繁に使われるカラム」に絞って作成することです。逆に、めったに検索条件にならないカラムや、値の種類が極端に少ないカラム（例: 性別のように2〜3種類しかない）にはインデックスの効果が薄くなります。本番環境でクエリが遅いと感じたら、まず EXPLAIN でインデックスが使われているか確認する習慣をつけると、パフォーマンス改善の第一歩になります。