PostgreSQL Performance & Query Optimization · レッスン

主キーと代理キーの設計

自然キー、連番の代理キー、UUIDのどれを選ぶかが、インデックスサイズ、挿入スループット、クエリ全体のパフォーマンスに与える影響を学びます。

レッスン 4/413 ステップ

「主キーと代理キーの設計」はCoddyKit上の無料PostgreSQL Performance & Query Optimizationレッスンです。これはレッスン4/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはPostgreSQL Performance & Query Optimization学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 PostgreSQL Performance & Query Optimizationコースには全4レッスンが含まれています。

このレッスンの一部はまだ翻訳されておらず、英語で表示されています。

Natural vs Surrogate Keys

A natural key is a real-world attribute (e.g. email). A surrogate key is a meaningless generated value (e.g. an integer id). Surrogate keys stay stable even when business data changes.

Why Key Choice Affects Performance

The primary key is referenced by every foreign key and many indexes. A wide key bloats all of those structures, increasing disk usage and cache pressure. Narrow keys keep indexes small and fast.

Sequential Integer Keys

The classic choice is a monotonically increasing integer. New rows append to the end of the B-tree, minimizing page splits and keeping inserts fast.

CREATE TABLE orders (
  id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  total NUMERIC
);

IDENTITY vs serial

Prefer the SQL-standard GENERATED ALWAYS AS IDENTITY over the older serial pseudo-type. It is cleaner and avoids ownership quirks with the underlying sequence.

The UUID Temptation

UUIDs are great for distributed systems because clients can generate them. But random UUIDs (v4) scatter inserts all over the index, causing page splits and poor cache locality.

CREATE TABLE events (
  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  payload JSONB
);

Time-Ordered UUIDs

If you need UUIDs, prefer a time-ordered variant (UUIDv7) so values increase roughly with time. This restores the append-friendly behavior of sequential keys while keeping global uniqueness.

Key Width Matters

A BIGINT is 8 bytes; a UUID is 16 bytes. Every secondary index stores the primary key, so wider keys multiply storage across all of them. Measure the impact.

SELECT pg_size_pretty(pg_relation_size('orders_pkey'));

Composite Primary Keys

Sometimes the natural key spans two columns, such as (order_id, line_no) in a detail table. Keep composite keys narrow and put the most selective column first.

CREATE TABLE order_lines (
  order_id BIGINT,
  line_no  INT,
  PRIMARY KEY (order_id, line_no)
);

Foreign Keys Inherit the Cost

Every child row stores a copy of the parent key. A 16-byte UUID parent key makes a million-row child table 8 MB larger than an 8-byte integer would. Multiply by every referencing table.

Choosing in Practice

Guidelines:

Default to BIGINT IDENTITY for single-database apps
Use time-ordered UUIDs when clients must generate ids or you shard
Avoid random v4 UUIDs as primary keys on hot insert paths
Keep composite natural keys short

Indexing the Foreign Key Side

Whatever key you pick, always index the child's foreign key column. Without it, deleting or updating a parent forces a full scan of the child table to check references.

CREATE INDEX idx_order_lines_order
ON order_lines (order_id);

Quick Check

Test your key-design knowledge.

対話的なレッスンで答える

Recap

You learned key design for performance:

Surrogate keys stay stable; natural keys can change
Narrow keys shrink every index and foreign key
Sequential BIGINT IDENTITY inserts are cheap
Random v4 UUIDs scatter inserts; prefer time-ordered UUIDs
Keep composite keys short and selective-first

無料で開始

AI チューターと学ぶ SQL — 無料

ブラウザでリアルコードを書いて実行し、24/7 の AI チューターから瞬時にサポートを受け、ウェブまたはアプリで続きから学習できます。

コース: 22
レッスン: 88

無料で学習を始めるコース全体を表示

よくある質問

「主キーと代理キーの設計」レッスンは無料ですか？

はい。「主キーと代理キーの設計」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、PostgreSQL Performance & Query Optimizationコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 PostgreSQL Performance & Query Optimizationコースには全4レッスンが含まれています。

「主キーと代理キーの設計」で何を学びますか？

自然キー、連番の代理キー、UUIDのどれを選ぶかが、インデックスサイズ、挿入スループット、クエリ全体のパフォーマンスに与える影響を学びます。ブラウザで直接実行するハンズオンコードでPostgreSQL Performance & Query Optimizationを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

PostgreSQL Performance & Query Optimizationを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのPostgreSQL Performance & Query Optimizationは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。これはレッスン4/4です。

「主キーと代理キーの設計」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このPostgreSQL Performance & Query Optimizationレッスンでコードを書いて実行できますか？

はい。すべてのPostgreSQL Performance & Query Optimizationレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

← PostgreSQL Performance & Query Optimizationに戻る