Back-End/DB

외래키 설정에 대해

Meluu_ 2025. 11. 4. 19:02

외래키 꼭 필요한가?

프로젝트를 하면서 '외래키 설정이 꼭 필요한가?' 라는 의문을 갖게 되었다.

물론 내 프로젝트처럼 소규모는 데이터 정합성과 무결성을 위해서 사용해도 성능상 큰 문제는 없다. 

그럼에도 불편한 점이 존재한다. 

 

초반 프로젝트를 막 설계하고 적용한 후 변경사항이 없을 수가 없고, 이로 인해 테이블을 변경하게 되는데

부모 테이블을 삭제하려니 FK 조건때문에 막히고,

 

테스트 시 현재 테스트에서 관심사가 아닌 연관관계가 설정된 테이블의 데이터도 함께 넣어줘야하므로 

생각보다 번거롭다고 느꼈다. <-- 이게 좀 큰 것 같다.

 

특정 부모를 참조하는 자식데이터들의 대량 insert 발생  (ex 댓글)

 

데이터
무결성 (Integrity)       : “데이터 자체가 논리적으로 올바른가?” — 잘못된 값이 들어오지 않도록 보호하는 제약 조건
정합성 (Consistency) : “서로 다른 데이터 간에 모순이 없는가?” — 시스템 전반의 데이터 일치 상태

 

 

FK가 어떤 프로세스로 진행되는지 알아보자

 

FK 검증시 InnoDB가 실제로 하는 일

자식 INSERT/ UPDATE

  • 자식 테이블에 데이터를 넣을 때 InnoDB는 부모 테이블의 참조 키가 존재하는지 인덱스로 조회
  • 부모 레코드에 S(Shared) 레코드 락
  • 이로 인해 부모 삭제/ 키 변경 시 X-락 필요로 S-락과 경합이 발생

 

부모 DELETE/ 키 UPDATE

  • 부모를 지우거나 참조 키 변경시 InnoDB는 자식 쪽에 참조가 남아 있는지 자식 FK 인덱스 검사
  • RESTRICT/NO ACTION : 자식 FK 인덱스 범위를 읽고 잠금 (참조 존재시 에러)
  • ON DELETE/UPDATE CASCADE : 자식 레코드들을 직접 DELETE/ UPDATE (대량 잠금/수정)
  • 부모 레코드 X-락 필요, 자식 다량의 레코드, 넥스트 키 락 전파

 

 

물론 신뢰성과 무결성이 중요한 거래등의 데이터는 FK를 설정해서 안전하게 처리하는 게 맞다.

 

하지만 거래가 아닌 게시글, 댓글 등 CRUD가 빈번하게 일어나는 테이블에 대해서 FK를 설정하여

성능 저하가 발생하는 것은 좋지 않다고 생각이 든다.

 

이에 따른 단점

  • 애플리케이션 단에서 검증 비용 발생
  • JPA 사용시 그래프 탐색, Fetch Join 불가
  • 무결성 보장 X
  • CASCADE 불가

정도로 생각된다. 

 

다음 프로젝트에서는 FK 없이 개발을 해보려한다. 

 

JPA에서 어떻게 사용할 것인가?

각 엔티티는 생성하되 연관관계 매핑을 하지않고, member_id 처럼 외래키 값만을 이용해서 처리한다.

이로 인해 그래프 탐색, 엔티티 조인이 막히지만

QueryDSL로 직접 ON 으로 id값을 연결해서 조인하면 된다.

 

'Back-End > DB' 카테고리의 다른 글

MYSQL DB 명 변경  (0) 2025.11.07
Real My SQL 8.0 [공간 데이터]  (1) 2025.09.25
Real MySQL 8.0 [실행계획 : Extra 칼럼]  (0) 2025.09.03
Real MySQL 8.0 [실행계획]  (4) 2025.09.01
락에 대하여  (0) 2025.08.20