[Project] 복합 키 적용 전후, MySQL 성능 차이 실험 - MySQLWorkBench

복합 키를 쓰면 정말 쿼리 성능이 좋아질까?

JPA에서 N:M 관계를 설계할 때, 중간 테이블에 고유 ID(@Id)를 쓸지, 복합 키(@EmbeddedId)를 쓸지는 꽤 자주 마주치는 고민이다.
이전 포스팅(복합 키를 사용할 때 주의할 점)에서는 주로 설계적인 장점을 다뤘다면, 이번엔 성능을 실제로 수치화해서 비교해봤다.

 

실험 배경

EduClass에서 ProblemSet(문제집)과 Problem(문제)은 N:M 관계를 갖는다. 이를 위해 중간 테이블 problem_set_to_problem을 설계했는데, 초기엔 단순하게 id를 기본 키로 쓰는 방식으로 구성했다.

 

하지만 두 가지 문제가 발생했다:

1. 중복 등록 방지 불가
   → 동일한 문제집-문제 조합이 여러 번 삽입됨
2. 조회 성능 저하
   → problem_set_id로 검색 시, 인덱스를 타지 않아 전체 조회를 해야하는 문제가 발생

실험 환경

• DB: MySQL 8.0
• Tool: MySQL Workbench
• 데이터: 문제집 100개, 문제 1,000개 → 랜덤 조합으로 100,000건 생성

실험 쿼리

SELECT * FROM problem_set_problem WHERE problem_set_id = 42;

실험 결과

 

결론

실제 성능 차이를 수치로 직접 확인할 수 있었다.

• 고유 ID가 의미 없는 테이블 → @EmbeddedId 적극 활용
• 복합 키로 무결성과 성능을 동시에 확보
• 단일 키 구조를 쓸 경우, 반드시 별도 인덱스 설계까지 고려할 것