4-1. 인덱스 크기와 조인 비용

자연 키와 대리 키의 선택은 설계 철학만의 문제가 아니라, 성능에도 직접적인 영향을 준다.

• 자연 키: 주민번호, 이메일처럼 길이가 길고 문자열인 경우가 많다.
• 대리 키: 보통 8바이트 정수 하나면 충분하다.

인덱스 입장에서 보면:

• 키가 길수록 인덱스 페이지에 담을 수 있는 엔트리 수가 줄어든다.
• 조인 연산 시, 키 비교에 드는 CPU 연산과 메모리 사용량이 늘어난다.

예를 들어, 다음 두 설계를 비교해 보자.

-- 자연 키 기반 PK
CREATE TABLE member (
  email      VARCHAR(255) PRIMARY KEY,
  name       VARCHAR(100) NOT NULL
);

CREATE TABLE orders (
  order_id   BIGINT AUTO_INCREMENT PRIMARY KEY,
  member_email VARCHAR(255) NOT NULL,
  order_dt   DATETIME       NOT NULL,
  CONSTRAINT fk_orders_member
    FOREIGN KEY (member_email) REFERENCES member(email)
);

-- 대리 키 기반 PK
CREATE TABLE member (
  member_id  BIGINT AUTO_INCREMENT PRIMARY KEY,
  email      VARCHAR(255) NOT NULL UNIQUE,
  name       VARCHAR(100) NOT NULL
);

CREATE TABLE orders (
  order_id   BIGINT AUTO_INCREMENT PRIMARY KEY,
  member_id  BIGINT       NOT NULL,
  order_dt   DATETIME     NOT NULL,
  CONSTRAINT fk_orders_member
    FOREIGN KEY (member_id) REFERENCES member(member_id)
);

두 설계 모두 기능적으로는 같다. 하지만 아래 차이가 발생한다.

• 조인 시 비교해야 하는 키의 크기: 255바이트 문자열 vs 8바이트 정수
• 인덱스 페이지 하나에 들어갈 수 있는 엔트리 수: 문자열 키 쪽이 훨씬 적다.

데이터가 수십만, 수백만 건 이상으로 커질수록 이 차이는 곧 성능 차이로 이어진다.

4-2. 복합 자연 키 vs 단일 대리 키

자연 키 하나로는 유일하지 않아서, 다음과 같이 복합 자연 키를 PK로 잡는 경우도 많다.

-- 상영 영화 좌석 예시
CREATE TABLE reservation (
  movie_title    VARCHAR(200) NOT NULL,
  screening_dt   DATETIME     NOT NULL,
  seat_number    VARCHAR(10)  NOT NULL,
  customer_id    BIGINT       NOT NULL,
  PRIMARY KEY (movie_title, screening_dt, seat_number)
);

이렇게 설계하면 다음과 같은 문제가 생긴다.

• 기본 키가 3개 컬럼으로 이뤄져 있어 모든 조인에 이 세 컬럼이 따라다녀야 한다.