主キーは行を識別するための制約・設計上のキー、インデックスはデータへのアクセスを効率化する仕組みです。主キーを支えるためにインデックスが使われることはありますが、両者は同じ概念ではありません。
役割と制約を比較
| 比較 | 主キー | インデックス |
|---|---|---|
| 中心の役割 | 行の一意な識別 | 検索などのアクセスを効率化 |
| 個数 | 1表に1つ。複数列で構成できる | 複数作成できる |
| 重複 | 主キー全体の値は重複不可 | 通常のものは許可。一意インデックスは一意性を強制 |
| NULL | 主キーの各列で不可 | DBMS・種類・設定によって扱いが異なる |
SQLでは主キーのない表も作れる場合がありますが、データ設計では行をどう識別するかを明確にします。主キーを複数列にすることと、主キー制約を複数作ることは別です。
氏名検索にインデックスを使う例
社員IDを主キーにした表でも、氏名から検索する処理が多いなら、氏名列に検索用のインデックスを検討できます。同姓同名を許すなら、氏名を一意にする必要はありません。「インデックスがある列はすべて主キー」とは限りません。
主キーと一意インデックスの関係
PostgreSQLではPRIMARY KEYを定義すると、一意なB-treeインデックスが自動作成され、各列にはNOT NULLが課されます。一方、独立した一意インデックスを作ることと、主キーとして宣言することは別です。ほかのDBMSでは実装も異なるため、製品の仕様を確認します。
インデックスがあっても必ず速くならない
返す行が多い場合や小さな表では、全体を走査した方が効率的な場合があります。DBMSは条件や統計などから実行計画を選ぶため、作成したインデックスが必ず使われるわけではありません。
保存と更新のコストも考える
インデックスには保存領域が必要で、データの追加・変更・削除時には関連するインデックスの維持処理も発生します。増やせばよいというものではなく、検索と更新の利用状況から検討します。インデックスは一般に行の表示順を保証するものでもなく、順番が必要な検索はORDER BYを指定します。
主キーの候補をどう選ぶかは、候補キーと主キーの関係で確認できます。
確認問題
氏名列に通常のインデックスがあれば、同姓同名の行は登録できなくなるでしょうか?また、その列が主キーになるでしょうか?
解答・解説を見る
どちらもいいえです。通常のインデックスと、一意インデックス・主キー制約は区別します。検索用のインデックスを作るだけで主キーになるわけではありません。
主キーから正規化をnoteで復習
関連noteでは主キー・複合主キーから関数従属・正規化へ進めます。検索の仕組みとの違いを理解した後は、表の識別と設計の基礎を復習できます。
ほかの教材は資格・目的別のnote教材ナビから選べます。

コメント