主キーのないテーブルは、システムが小さいうちは無害に見えます。しかし規模が大きくなると問題が表面化します。主キーの欠落は、重複データ、CDC パイプラインの破綻、レプリケーションの停止、整合しない分析を引き起こします。
Bytebase の SQL レビューにはこのルールが含まれます。
SQL が主キーを持たないテーブルを作成しようとしたり、主キーを削除しようとした場合、Bytebase はこのルール違反とみなします。SQL が主キー内のすべてのカラムを削除する場合も、主キーを削除したものとみなします。
主キー欠落による実例
PostgreSQL の論理レプリケーションが壊れる PK が無いと、Postgres は論理レプリケーション (や Debezium) で UPDATE/DELETE を適用できません。 参考: TIL: Creating tables without primary keys CAN cause updates and deletes to fail in Postgres
Matomo の本番レプリケーションが停止 主キーのない単一テーブルが原因で、MySQL の master–slave レプリケーションが止まりました。 参考: Master–Slave Replication Stalls Because of Missing Primary Key
GitLab がスキーマ不整合を報告 GitLab のエンジニアは、主キーのないテーブルが環境ドリフトと保守の問題を引き起こしていることを発見しました。 参考: Database schema missing many primary keys - breaks replication
主キーが無いとなぜ危険か
1. 重複行が紛れ込む
PK が無いと、データベースは一意性を強制できません。 偶発的な重複が現れ、分析やレポートを汚染します。
2. CDC が行の変更を追えなくなる
Debezium や Kafka Connect のようなツールは、安定した行 ID を必要とします。 PK が無いと → 正しい UPDATE/DELETE イベントを発行できません。
3. レプリケーションが停止または逸脱する
MySQL も PostgreSQL も、レプリケーションで主キーに依存します。 PK が無いとレプリケーションが止まったり、同期がずれたりします。
4. UPSERT が正しく動かない
INSERT … ON CONFLICT、MERGE、UPSERT パターンは PK を必要とします。
PK が無いと、データベースは衝突を確実に解決できません。
5. デバッグが当てずっぽうになる
一意の行識別子が無いと、特定のレコードを狙えません。 1 行の削除、修正、調査が安全に行えなくなります。
主キーの無いテーブルをどう修正するか
1. サロゲート主キーを追加する
ALTER TABLE events
ADD COLUMN id BIGSERIAL PRIMARY KEY;2. 適切ならナチュラルな複合キーを使う
ALTER TABLE order_items
ADD PRIMARY KEY (order_id, line_number);3. サロゲート PK と業務一意キーを組み合わせる
ALTER TABLE shipments
ADD COLUMN id BIGSERIAL PRIMARY KEY,
ADD CONSTRAINT shipments_unique UNIQUE (tracking_number);