回答編集履歴
1
修正
answer
CHANGED
|
@@ -1,10 +1,10 @@
|
|
|
1
1
|
> 1. 主キー索引・ユニーク索引はテーブル定義時にPRIMARY KEY制約・UNIQUE制約を付与した列に関しては自動でインデックスが作られるのでしょうか？
|
|
2
2
|
|
|
3
|
-
INSERT
|
|
3
|
+
INSERTするキーが既に存在しているものかどうかを確認するには索引を見るのが効率的なので、ほとんどのRDBMSでは自動的に索引が作られます。もしくは、既存の索引で利用できるものがあれば新たに作成せずそれを確認に使用するようになるケースもあります。
|
|
4
4
|
|
|
5
5
|
> 2. PRIMARY KEY制約・UNIQUE制約をテーブル定義時に付与していない列に関して主キー索引・ユニーク索引は作れるのでしょうか？
|
|
6
6
|
|
|
7
|
-
通常ALTER TABLEやCREATE INDEX文で後から追加可能です。
|
|
7
|
+
通常ALTER TABLE文やCREATE INDEX文で後から追加可能です。
|
|
8
8
|
|
|
9
9
|
> 3. 索引はどのように使い分けるのでしょうか？
|
|
10
10
|
索引の順番と実データの順番を同じにするクラスタ索引がもっとも効率がよく思われます。
|
|
@@ -12,4 +12,4 @@
|
|
|
12
12
|
|
|
13
13
|
クラスタ索引は性能を最も向上させたいSQLの結果の順序に合わせて作成します。テーブルのレコードはそのクラスタ索引の順序に並んでいるため、それ以外の索引を作成しようとするとそれはどうしても非クラスタ索引ということになってしまいます。
|
|
14
14
|
|
|
15
|
-
非ユニーク索引はデータを一意に
|
|
15
|
+
非ユニーク索引はデータを一意に特定することはできなくても、テーブル全体から一部のレコードを効率的に抽出することが可能であれば作成する意味があります。例えば、従業員テーブルの部署カラムに索引を張ると、通常部署に従業員は複数いるため非ユニーク索引となりますが、特定の部署の従業員レコードだけ抽出するようなSQLを効率化できます。
|