기본키는 수정이 가능한가요?

기술적으로는 가능하지만, 실무에서는 절대 하지 않는 것이 원칙입니다.

기본키 수정이 위험한 이유

-- user 테이블
| id | email         |
|----|---------------|
| 1  | kim@test.com  |

-- orders 테이블 (FK 참조 중)
| order_id | user_id |
|----------|---------|
| 101      | 1       |
| 102      | 1       |

-- id = 1 을 id = 99 로 변경 시도
UPDATE user SET id = 99 WHERE id = 1;

-- X FK 제약조건 위반 에러
-- orders.user_id = 1 이 참조하는 대상이 사라지기 때문

ON UPDATE 옵션으로 가능하긴 함

FOREIGN KEY (user_id) REFERENCES user(id)
    ON UPDATE CASCADE  -- PK 변경 시 FK도 자동으로 따라서 변경

-- CASCADE 설정 시
UPDATE user SET id = 99 WHERE id = 1;

-- orders 테이블도 자동 변경됨
| order_id | user_id |
|----------|---------|
| 101      | 99      |  ← 자동 변경
| 102      | 99      |  ← 자동 변경

그럼에도 하지 않는 이유

이유설명
참조 무결성 위험CASCADE 미설정 시 FK 에러
성능 저하참조 테이블이 많을수록 연쇄 UPDATE 비용 증가
캐시 불일치Redis 등 캐시에 저장된 PK 값이 남아있음
로그 추적 불가변경 전 PK로 기록된 로그가 무의미해짐

결론

기본키는 불변(Immutable) 이어야 한다. 이것이 실무에서 비즈니스 의미 없는 대리키(AUTO_INCREMENT, UUID) 를 선호하는 가장 큰 이유입니다.

자연키(이메일, 주민번호 등)는 언제든 변경될 수 있지만, 대리키는 변경될 이유 자체가 없기 때문입니다.

CSLOG에서 보기