PREPARATION
受験対策

一般に、索引は検索を速くするために作られます。RDBMSのパフォーマンスに大きく影響を与えるのはディスクの読み書きです。単純に、ディスクアクセスの量が多いほど時間がかかる、と考えても良いでしょう。索引がないときは、テーブルからの検索において、データファイルをすべて読み込む必要があります。データファイルは巨大なことが多いですから、これには時間がかかります。索引があれば、索引ファイルの一部を読み込み、それに対応するデータファイルの一部を読み込むだけで済むかもしれません。これによりディスクアクセスの量が減れば、テーブルからの検索が速くなります。

では、簡単な例で考えましょう。
CREATE TABLE table1 (id INTEGER, val VARCHAR(50));
で定義されたテーブルに対して、
(1) SELECT * FROM table1 WHERE id = 1;
(2) SELECT * FROM table1 WHERE val = 'abc';
という検索を実行するとします。

索引がなければ、table1 のデータファイルをすべて読み込む必要があります。

CREATE INDEX ON table1 (id)；
とすると、table1 の id 列に索引が作られます。

この場合、(1)の SELECT 文では索引が使われて、普通は検索が高速になります。一方で(2)では、val 列の値を調べたいため、id 列の索引は意味をなしませんから、索引が使われず、検索は高速になりません(Dは誤り)。

さらに
CREATE INDEX ON table1 (val)；
とすると、table1 の val 列にも索引が作られます。

この場合、(1)の SELECT 文では、id 列の索引が、(2)では val 列の索引がそれぞれ使われ、普通はいずれも高速に実行されます(Cは誤り)。

なお、索引の有効性はデータの分布にも依存します。例えば上の例で table1 に10000行のデータがあったとして、うち5000行は id=1、残りの5000行の id=2、という分布になっているとき、(1)の SELECT 文で索引を使ったとしても、データファイルの大部分を読み込む必要があるため、かえって検索が遅くなる可能性が高いです(Aは誤り)。

次にデータを更新するケースを考えます。索引があると、テーブルの更新時に索引も更新しなければならず、その分、更新が遅くなるので、不要な索引は作るべきではありません。

上の table1 の例で
UPDATE table1 SET val = 'xyz' WHERE id = 1;
という UPDATE 文を考えてみましょう。

この場合、第1のステップは更新対象となるデータを特定することですから、id=1 のデータを探すことになります。id 列に索引がなければデータファイルをすべて読み込むことになりますが、id 列に索引があれば、普通は索引ファイルとデータファイルの一部だけを読み込めば十分です。
2番目のステップは、データファイルの該当部分の更新と、索引ファイルの更新です。索引ファイルの数が多ければ、更新は遅くなりますが、全体のパフォーマンスは第1のステップと合わせて考える必要がありますから、普通は id 列に索引があった方が更新が速くなります(Bは誤り)。

というわけで、正解はEです。