PostgreSQL Performance & Query Optimization · 강의

기본 키와 대체 키 설계

자연 키, 순차 대체 키, UUID 중 어떤 것을 선택하느냐가 인덱스 크기, 삽입 처리량, 전체 쿼리 성능에 미치는 영향을 배워 보세요.

기본 키와 대체 키 설계은(는) CoddyKit의 무료 PostgreSQL Performance & Query Optimization 강의입니다. 이것은 4개 중 4번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 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

자주 묻는 질문

“기본 키와 대체 키 설계” 강의는 무료인가요?

네 — “기본 키와 대체 키 설계” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 PostgreSQL Performance & Query Optimization 강의 전체를 잠금 해제할 수 있습니다. PostgreSQL Performance & Query Optimization 강의에는 총 4개의 강의가 포함되어 있습니다.

“기본 키와 대체 키 설계”에서 뭘 배우나요?

자연 키, 순차 대체 키, UUID 중 어떤 것을 선택하느냐가 인덱스 크기, 삽입 처리량, 전체 쿼리 성능에 미치는 영향을 배워 보세요. 브라우저에서 직접 실행하는 실습 코드로 PostgreSQL Performance & Query Optimization을(를) 배우며, 24/7 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(으)로 돌아가기