主キー（しゅキー、英語: primary key）とは、関係データベースにおいて、組（レコード）の識別子として利用するのにもっとも好ましいものとして、関係（テーブル）毎にただ一つ設計者により選択・定義された候補キーをいう。つまり、関係に格納されたレコードを一意に識別するための属性（列、アトリビュート）またはその集合のうち、そのために通常利用されるべき特定の一つをいう。

関係データベース管理システム（RDBMS）やミドルウェア、アプリケーションなどでレコードの識別子が必要な場合、主キーがそのために使われることが多い。ただ、そうしなければならない必然性はなく、他の候補キーを使っても良い。したがって、主キーの理論上の意義は大きくないが、実務上は、そのわかりやすさなどから広く使われている概念である。 ただし、主キーにはNULLの存在が許されないが、候補キーには許されるという差があるとする立場もある（レコードの追加、更新時の制約として主キーを考える場合、一意性制約にNOT NULL制約を加えたものが主キー制約であると考えることができる）。

関係に存在する候補キーが一つであるときは、その候補キーが当然に主キーとなる。

なお、主キーでない候補キーは代理キー（alternate key）という。

• 生徒名簿（生徒番号, 生徒名, クラス）という関係の場合、生徒番号が主キーになり得る。同姓同名を考慮すると、生徒番号は唯一の候補キーであるから、代理キーはない。
• 町村（町村ID, 町村名, 郡名, 都道府県名）という関係の場合、町村ID と {都道府県名, 郡名, 町村名} が候補キーであり、いずれかが主キーになり得る。例えば、町村ID を主キーにした場合、{都道府県名, 郡名, 町村名} は代理キーとなる。

候補キーが複数あるとき、組を識別するという機能においてそれらの間に差異はないから、主キーにどれを選んでも論理的には問題がない。しかし実用上は、以下のような指針に従って選択するのがよい。

• 主キーは検索のキーとして利用されたり、他の関係に参照のために格納されたりする確率が高いため、できる限りデータ量の小さい方がよい。よって、複合キーはあまり適さない。データ量が多いキーしかない場合は、人工キー（後述）を設けることがある。
• 主キーは検索のキーとして利用されるほか、電話や書面で伝達されることも多いので^[要出典]、簡潔に間違いなく伝達できる形式であるのが望ましい。一定の桁数のアルファベットや数字からなる主キーは、この点でも優れている。
• 主キーはその関係の外部（他の関係や、外部システム、ユーザなど）で識別子として利用される確率が高いため、不変 (immutable) であるべきである。つまり、更新がかからない項目がよい。例えば、他の関係で主キーを使用していた場合、主キーを更新すると他の関係の値（外部キー）も同時に更新しなければならなくなる。また、外部システムなどに所在するデータについては、このような更新が不可能なことがありうる。なお、人工キーは通常、それ自体に意味を持たないため、不変であるから、この問題も避けることができる。

関係（テーブル）作成の際に、以下のようにSQLステートメントを記述して主キーを設定する。

　1. テーブル制約として定義する方法：

CREATE TABLE テーブル名 (
      列名1 列1データ型,
      列名2 列2データ型,
      …,
      CONSTRAINT キー名 PRIMARY KEY(列名1)
);

　2. 列制約として定義する方法：

CREATE TABLE テーブル名 (
      列名1 列1データ型 CONSTRAINT キー名 PRIMARY KEY,
      列名2 列2データ型,
      …
);

　3. 複数の列に対して主キーを設定する方法：

CREATE TABLE テーブル名 (
      列名1 列1データ型,
      列名2 列2データ型,
      …,
      CONSTRAINT キー名 PRIMARY KEY(列名1,列名2・・)
);

　4. ALTER TABLE ステートメントを使うこともできる。

連番（順序・シーケンスとも呼ばれる）のように、一意性を確保するためだけにシステム内部で生成され、利用者が関知しない情報を格納する属性からなる主キーを人工キー、人為キー (artificial key) ないし別名キー (alias key)、代替キー (surrogate key) などといい、逆に、システム外部から格納すべきものとして与えられる情報を格納する属性からなる主キーを自然キー (natural key) ということがある。

利用者が関知しないという点について、エドガー・F・コッドによる定義では、人工キーの値が、利用者に提示されたり、利用者の発行する問い合わせのキーとなったりしないことが要求されている。しかし一般には、単に利用者の意向と無関係にシステムが生成するものを広く人工キーと呼ぶことも多い。

設計された関係の属性に候補キーがない場合には、人工キーを付け加えざるを得ないが（前述の生徒名簿関係に生徒番号がなかった場合を考えよ）、そうでない場合にも人工キーを付け加えるべきか、そのようなことは避けて自然キーを使うべきかについては議論がある。自然キーには、関係に余計な属性を付け加える必要がないという利点があるが、複合キーになりがちであるし、外部の状況が変化すれば変更も必要となるから、前述の指針からみると望ましくない選択となることがありうる。人工キーの利点・欠点はその逆である。実際には、これらの得失のバランスは、場合により異なるから、ケース・バイ・ケースで判断すべきであろう。

• 一意性制約
  • スーパーキー
  • 候補キー
  • 代理キー
• 外部キー
• 関係の正規化
• NOT NULL制約

表 話 編 歴 データベース管理システム
データモデル 関係モデル データベース設計 正規化 参照整合性 関係代数 関係論理 データベース管理システム 関係データベース管理システム オブジェクト関係データベース 分散データベース トランザクション処理
概念	データベース ACID CRUD 3値論理（NULL） 候補キー 外部キー 主キー スーパーキー 代理キー
オブジェクト	関係 (表) ビュー トランザクション ログ トリガ 索引 ストアドプロシージャ カーソル 分割
SQL	SELECT INSERT UPDATE MERGE DELETE JOIN CREATE DROP COMMIT ROLLBACK TRUNCATE ALTER WHERE SAVEPOINT
構成要素	並行性制御 データ辞書 JDBC ODBC データベース言語 問い合わせ言語 クエリ最適化 クエリ実行計画
データベース製品 関係データベース管理システムの比較 データベース接続クライアント カテゴリ