✅ MySQL 테이블 간 관계 설정 – 물리적 FK vs 논리적 FK, 그리고 Lock 이슈까지!

MySQL에서 여러 테이블을 연관시키는 방법에는 두 가지가 있습니다.

1. 물리적으로 Foreign Key 제약조건(FK)을 설정하는 방법
2. 논리적으로만 관계를 유지하는 방법

각 방식은 장단점이 뚜렷하고, 시스템의 구조나 규모에 따라 적절한 선택이 중요합니다. 이번 글에서는 두 방식의 차이점과 함께, 물리적 FK 사용 시 발생할 수 있는 Lock 이슈까지 실무 관점에서 자세히 살펴보겠습니다.

---

📌 예시 테이블 – 사용자와 게시글

설명을 돕기 위해 사용자(User)와 게시글(Post) 테이블을 사용하겠습니다.

💡 물리적으로 FK 제약조건을 설정한 경우

CREATE TABLE User (
    user_id INT PRIMARY KEY,
    username VARCHAR(50) NOT NULL
);

CREATE TABLE Post (
    post_id INT PRIMARY KEY,
    user_id INT,
    title VARCHAR(100),
    content TEXT,
    FOREIGN KEY (user_id) REFERENCES User(user_id)
);

💡 논리적으로만 관계를 설정한 경우 (제약조건 없음)

CREATE TABLE User (
    user_id INT PRIMARY KEY,
    username VARCHAR(50) NOT NULL
);

CREATE TABLE Post (
    post_id INT PRIMARY KEY,
    user_id INT,
    title VARCHAR(100),
    content TEXT
    -- FOREIGN KEY 생략
);

---

⚖️ 물리적 FK 설정 – 장점과 단점

✅ 장점

• 데이터 무결성 보장 – 참조되지 않은 user_id는 Post에 저장 불가
• 자동 삭제/수정 지원 – ON DELETE CASCADE 등을 이용한 자동 처리 가능
• 데이터 모델 명확화 – ERD 도구 등에서 관계 시각화 용이

❌ 단점

• 성능 저하 가능 – 무결성 검사로 인해 DML 성능 저하
• 마이그레이션 어려움 – 테이블 이동이나 구조 변경 시 제약 존재
• Sharding 불가능 – FK는 같은 DB 내에서만 유효

---

⚖️ 논리적 FK 설정 – 장점과 단점

✅ 장점

• 유연한 설계 – 구조 변경이나 마이그레이션에 유리
• 성능 향상 – 제약조건이 없어 빠른 DML 가능
• 분산 시스템 호환 – 마이크로서비스나 샤딩 구조에서 유리

❌ 단점

• 무결성 직접 관리 필요 – 앱 레벨에서의 관리 필요
• 데이터 일관성 책임 증가 – 직접 트리거나 로직 처리 필요
• 관계 파악 어려움 – DB 스키마만 봐서는 관계 확인 어려움

---

🔒 물리적 FK와 트랜잭션 Lock – 연관 테이블도 Lock이 걸릴까?

물리적으로 Foreign Key를 설정한 경우, INSERT/UPDATE/DELETE 작업 시 MySQL은 참조 무결성 검사를 위해 연관 테이블에 Lock을 걸 수 있습니다.

🧪 예제 상황

📌 DELETE from User

DELETE FROM User WHERE user_id = 1;

• MySQL은 Post 테이블에서 해당 user_id를 참조하는 데이터가 있는지 확인함
• 연관 데이터가 있다면: 삭제 거부 또는 CASCADE 처리
• Post 테이블의 관련 인덱스에 공유 락(Shared Lock) 발생 가능

📌 INSERT into Post

INSERT INTO Post (post_id, user_id) VALUES (100, 1);

• User 테이블의 존재 여부 확인을 위해 읽기 락(Read Lock) 발생

🔧 FK로 인한 Lock 요약

작업 유형	대상 테이블	Lock 유형	설명
INSERT (자식)	부모 테이블	Read Lock	참조 무결성 검사
DELETE (부모)	자식 테이블	Shared Lock	연관된 자식 데이터 검사
UPDATE (PK 변경)	자식 테이블	Shared/Exclusive	무결성 위반 방지를 위한 잠금

💡 실무 팁: 대량 작업 시 FK 끄기

SET FOREIGN_KEY_CHECKS = 0;
-- 작업 수행
SET FOREIGN_KEY_CHECKS = 1;

주의: 이 설정은 무결성을 직접 보장해야 하므로 신중하게 사용하세요.

---

🧠 결론 – 어떤 방식을 언제 써야 할까?

상황	추천 방식
데이터 무결성이 최우선	✅ 물리적 FK
시스템 구조가 유동적 / 대용량 처리	✅ 논리적 FK
분산 시스템 / 마이크로서비스	✅ 논리적 FK
ERD 도구로 관계 시각화 필요	✅ 물리적 FK
트랜잭션 충돌을 줄이고 싶을 때	✅ 논리적 FK

---

✨ 마무리

물리적 FK는 무결성을 DB 자체에서 강력하게 보장해주기 때문에 작고 정형화된 시스템에 적합합니다. 반면 논리적 FK는 성능과 유연성 측면에서 유리해 대규모 시스템이나 분산 환경에서 많이 쓰입니다.

어떤 방식이 더 “좋다”기보다는, 내 시스템의 구조와 요구사항에 맞는 방식을 선택하는 것이 중요합니다. 실무에서는 두 방식을 혼합해서 쓰는 경우도 많으니, 적절하게 전략을 세워보세요!

---