PK（主キー）、FK（外部キー）、インデックス設計とは？
データベース設計において、PK（Primary Key）、FK（Foreign Key）、およびインデックスは、構造の整合性と性能の両方を支える最も基本かつ重要な構成要素である。それぞれの役割を理解し、適切に設計することが、高品質なデータベースの構築と保守に繋がる。
かつて、ある老舗メーカーが業務基幹システムを刷新する際に、担当エンジニアが「パフォーマンスはアプリケーション側でなんとかなる」と判断し、FKとインデックスの設定を最小限に留めた。しかし導入後、「削除したはずのデータにまだ紐づくレコードがある」「集計レポートが遅すぎる」といった問題が多発。原因は、参照整合性を守るFKの欠如と、検索頻度の高いカラムにインデックスが設定されていなかったことだった。その後、再設計を経てFK制約とインデックス設計を全面的に見直し、応答速度と整合性の両立を実現した。この経験は、基本の大切さを現場に再認識させる出来事となった。
1. 主キー（Primary Key：PK）とは？
主キーは、テーブル内の各行を一意に識別するための列（または列の組み合わせ）である。
- 目的：データの一意性を保証する
- 特徴：NULL不可、重複不可
- 例：ユーザーテーブルの「user_id」、注文テーブルの「order_id」など
ある病院管理システムでは、「患者番号」を主キーとして使用することで、同姓同名の患者がいてもデータの混同を避けることができた。
2. 外部キー（Foreign Key：FK）とは？
外部キーは、別のテーブルの主キーを参照し、テーブル間の関係性を定義する列である。
- 目的：リレーション（関係）を表現し、データ整合性を保つ
- 制約：参照整合性制約により、不整合データの登録を防止
- 例：注文テーブルの「user_id」がユーザーテーブルの「user_id」を参照
ECサイトのデータベースでは、商品のレビューを管理するテーブルで「product_id」を外部キーとして設定し、存在しない商品へのレビュー登録を防止している。
3. インデックス（Index）とは？
インデックスは、特定のカラムに対する検索速度を向上させるために作成される補助的なデータ構造である。
- 目的：検索クエリの高速化（特にWHERE句やJOINでの使用）
- 種類：B-treeインデックス、ユニークインデックス、複合インデックス、全文検索インデックスなど
- 注意点：更新処理が多いテーブルでは、インデックスの乱用はパフォーマンスを悪化させる可能性あり
あるニュースメディアでは、アクセスログテーブルに「access_time」に対してインデックスを設けた結果、過去1週間のアクセス分析処理が1/5の時間で完了するようになった。
4. 3要素の連携と設計のベストプラクティス
- 主キーに対しては必ずインデックスが自動的に生成される（RDBMSによる）
- 外部キーにも検索頻度が高ければインデックスの付与を検討
- インデックス設計は、クエリパターン・データ件数・更新頻度に応じて柔軟に
ある地方自治体の人事データベースでは、異動履歴の参照に時間がかかっていたが、「部署ID」「異動日」にインデックスを追加することで、担当者の処理時間が数十秒から2秒に短縮され、業務効率が飛躍的に向上した。
5. 実践的な失敗と学び
あるプロジェクトでは、外部キーの参照制約を一切設けずに開発が進んだ結果、運用後に「存在しない顧客に紐づく注文」が多数登録され、会計処理に混乱をもたらした。後に外部キー制約を導入し、合わせてインデックスを設けたことで検索性能も改善された。
担当エンジニアは「面倒でも初期段階でキー制約とインデックスをきちんと設計しておけば、こんな大事にはならなかった」と語っていた。
まとめ
PK、FK、インデックスは、それぞれがデータの一貫性、結合関係、処理性能を支える柱である。個別に理解するだけでなく、これらを連携させて設計することが、スケーラブルかつ堅牢なシステムを構築する上で不可欠である。
データベースは「読む」「書く」「つなぐ」すべての操作の精度とスピードが要求される世界。だからこそ、基本設計の段階で“当たり前”を丁寧に積み上げることが、後の信頼性と安定性を支えるのだ。
そして、技術者が見落としがちなのは「設計の手間を惜しんだ代償の大きさ」である。きちんと設計されたPK、FK、インデックスが、未来のエラーやパフォーマンス問題を防ぐ“保険”であることを、現場の経験は常に物語っている。
