[신입 개발자 면접 준비] 면접 스터디 2차 (DATABASE)

2024.12.27

스터디원들과 2차 면접 스터디를 진행하였다. 이 날도 조금이긴 하지만 눈이 왔다... 만날 때마다 눈이라니~ 신기하다 허허

한 3주 정도 Database 에 관해서 각자 공부를 진행하고, 공부한 내용을 발표하면서 많은 지식을 쌓았다.

2차 면접 스터디도 6명이 각자 돌아가면서 면접 질문을 하고, 각자 정답을 알거나 아는 부분이 있으면 먼저 이야기하고, 다른 사람들은 답변이 부족하거나 틀리다면 다시 답변을 보충할 수 있도록 하였다!

---

면접 질문 리스트

1. 인덱스와 키의 차이점은 무엇인가요?

키는 데이터의 고유성과 참조 무결성을 보장하는 요소로 Primary Key, Foreign Key 등 이 있습니다.

인덱스는 검색 속도를 높이기 위해 사용하는 자료구조로, 데이터를 효율적으로 찾고 정렬하기 위해 사용합니다.

 

2. 트랜잭션의 커밋과 롤백의 차이에 대해서 설명하세요.

커밋은 트랜잭션이 성공적으로 끝난 후 변경 사항을 데이터베이스에 영구 저장하는 것을 말합니다.

트랜잭션의 일부 또는 전체 작업이 실패하거나 예외가 발생한 경우, 데이터베이스를 트랜잭션 이전 상태로 복구하는 것을 말합니다.

 

3. 영속성 컨텍스트와 그 기능을 말해보세요.

• 영속성 컨텍스트(Persistence Context)는 엔티티(Entity)를 영속화하고 관리하는 환경이다.
  • JPA에서 엔티티 매니저(EntityManager)가 영속성 컨텍스트를 통해 엔티티를 관리합니다.
    
    1. 엔티티 관리: 영속 상태(Persistent)의 엔티티를 관리하며, 특정 엔티티를 영속성 컨텍스트에 저장하면 데이터베이스에 즉시 저장되지 않고 트랜잭션이 커밋될 때 반영됩니다.
    2. 쓰기 지연(SQL 저장소 관리): 데이터베이스 변경 작업(insert, update, delete 등)이 SQL 저장소에 보관되고, 트랜잭션이 커밋될 때 한꺼번에 실행됩니다. 이를 통해 성능을 최적화할 수 있습니다.
    3. 변경 감지(Dirty Checking): 영속성 컨텍스트에 저장된 엔티티의 상태를 지속적으로 감시하며, 변경된 사항을 자동으로 감지해 데이터베이스에 반영합니다.
    4. 1차 캐시: 영속성 컨텍스트는 1차 캐시 역할을 수행하여, 동일한 트랜잭션 내에서 조회된 엔티티를 재사용합니다. 이를 통해 데이터베이스 접근을 최소화할 수 있습니다.
    5. 지연 로딩(Lazy Loading): 실제로 필요할 때 데이터베이스에서 데이터를 가져옵니다.
  • 트랜잭션이 커밋되면 영속성 컨텍스트의 쓰기 지연 SQL 저장소에 저장된 쿼리들이 실행되며, 데이터가 영구적으로 저장됩니다.

 

4. 정규화(Normalization)와 비정규화(Denormalization)는 무엇인가요?

정규화는 데이터 무결성을 유지하기 위해 잘 정의된 방식으로 테이블을 분할하여 데이터베이스에서 중복 데이터를 제거하는 프로세스입니다. 즉, 관계형 데이터베이스에서 중복을 최소화하기 위해 데이터를 구조화하는 작업입니다. 이 프로세스는 많은 저장 공간을 절약합니다.

비정규화는 복잡한 쿼리 속도를 높이고 성능을 향상하기 위해 테이블에 중복 데이터를 추가하는 프로세스입니다.

꼬리질문 1 ) 정규화의 장단점은? 

• 장점: 데이터베이스 변경 시 이상 현상을 제거하고, 데이터베이스 구조 확장 시 재디자인을 최소화합니다.
• 단점: 릴레이션 분해로 인해 릴레이션 간의 연산(join)이 많아집니다. 이로 인해 응답 시간이 느려질 수 있습니다.

꼬리질문 2 ) 비정규화의 장단점은? 

• 장점: 조인 비용 감소하고, 읽기 성능 향상됩니다.
• 단점: 데이터 일관성 유지 어렵고, 저장 공간 증가합니다.

 

5. JOIN에 대해서 설명해 주세요.

JOIN: 두 개 이상의 테이블을 결합하여 하나의 결과 집합을 생성하는 연산입니다. 데이터베이스에서 다수의 테이블 간 연관 데이터를 결합하여 활용할 때 사용됩니다.

• JOIN의 주요 유형
  1. Inner Join은 두 테이블에서 교집합에 해당하는 데이터만 반환합니다. 조건에 맞는 행만 결과로 포함되므로, 조건에 해당하지 않는 데이터는 제외됩니다.
  2. Outer Join: 테이블 간 교집합 외에도 조건에 맞지 않는 데이터까지 포함하는 연산입니다. 종류에 따라 반환되는 데이터 범위가 다릅니다.
     • Left Outer Join: 왼쪽 테이블의 모든 데이터와 조건에 맞는 오른쪽 테이블의 데이터를 반환합니다.
     • Right Outer Join: 오른쪽 테이블의 모든 데이터와 조건에 맞는 왼쪽 테이블의 데이터를 반환합니다.
     • Full Outer Join: 양쪽 테이블의 모든 데이터를 반환하며, 조건에 맞지 않는 데이터는 NULL로 표시됩니다.
  3. Cross Join: 두 테이블의 데이터 간 가능한 모든 조합을 반환합니다. 결과 집합의 크기는 두 테이블 행 개수의 곱으로 결정됩니다.
  4. Self Join: 동일한 테이블을 기준으로 자신과 결합하여 데이터를 조회하는 연산입니다. 예를 들어, 계층 구조(부모-자식 관계)를 표현할 때 사용됩니다.

 

6. PK 길이가 길어질 때의 문제와 해결 방안

• 인덱스 크기 증가: 클러스터드 인덱스는 데이터를 정렬하기 위해 인덱스 키를 기준으로 데이터 페이지를 관리합니다. PK가 길어지면 인덱스 크기가 커져 데이터베이스의 저장 공간이 더 많이 필요해지고, 인덱스 페이지 간 이동 비용이 증가합니다.
• 성능 저하: PK는 다른 테이블에서 Foreign Key로 참조될 가능성이 높은데, 이 경우 참조하는 테이블에도 동일한 키가 저장됩니다. PK가 길어질수록 참조 테이블의 인덱스 크기도 커지며, 조인 및 검색 성능이 저하됩니다.
• 페이지 스플릿 문제: 데이터가 삽입될 때 정렬된 구조를 유지하기 위해 기존 페이지가 분할(페이지 스플릿)되는데, PK가 길면 페이지 분할이 더 자주 발생하여 성능 저하로 이어질 수 있습니다.

해결 방안으로는,

• 숫자형 PK 사용: int 또는 bigint 타입과 같이 짧고 정렬이 간단한 데이터 타입을 사용하는 것이 효과적입니다.
• 서로 증가하는 값(Sequential PK): PK 값이 순차적으로 증가하면 페이지 스플릿을 줄이고 클러스터드 인덱스의 효율성을 높일 수 있습니다.
• 해시 키 사용: 분산 시스템에서 고유성을 유지하면서 효율적으로 키를 생성할 수 있습니다.

---

++참고

- 페이지 스플릿 발생?

• 테이블에 데이터를 삽입할 때, 데이터가 클러스터드 인덱스의 정렬 순서에 따라 삽입되지 않으면 기존 페이지가 분리되고 새로운 페이지가 생성됩니다. 이를 페이지 스플릿이라 합니다.
• 페이지 스플릿은 추가적인 디스크 I/O와 CPU 작업을 유발하여 성능 저하를 초래합니다.

- 클러스터드 인덱스?

• 클러스터드 인덱스는 테이블의 데이터가 인덱스 키 순서에 따라 물리적으로 정렬되는 데이터 구조입니다.
• Primary Key는 보통 기본적으로 클러스터드 인덱스로 설정됩니다.
• PK에 의해 레코드의 물리적인 저장위치가 결정되게 됩니다. 이때 데이터를 B트리 자료구조로 PK값과 자식노드의 페이지번호가 매핑되게 저장합니다. 그리고 트리의 리프노드에는 실제 데이터가 위치하게 됩니다.

 

7. RDBMS가 수평 확장에 불리한 이유는 무엇인가요?

관계형 데이터 구조상 테이블 간의 관계(FK) 유지를 위해 여러 서버에 데이터를 분산 저장하기 어렵습니다. 또한, 조인이 필요한 경우, 여러 서버에 분산된 데이터를 결합해야 하므로 성능 저하가 발생합니다.

 

8. 데이터 무결성을 지키기 위한 제약 조건

• 개체 무결성: PK는 중복되거나 NULL 값을 가질 수 없습니다.
• 참조 무결성: FK는 NULL 값을 가질 수 없으며 참조하는 테이블의 PK와 일치해야 합니다.
• 도메인 무결성: 속성은 지정된 데이터 타입과 값 범위 내에서만 값을 가질 수 있습니다.

 

9. 클러스터링의 장단점

• 장점:
  • 고가용성(High Availability): 여러 서버로 구성되어 하나의 서버가 다운되더라도 다른 서버가 이를 대체해 서비스가 지속됩니다.
  • 확장성(Scalability): 수평 확장이 가능하므로 사용량이 증가할 때 더 많은 서버를 추가하여 처리 용량을 높일 수 있습니다.
  • 부하 분산(Load Balancing): 요청이 여러 서버로 분산 처리되므로 시스템 성능과 응답 속도가 향상됩니다.
• 단점:
  • 클러스터링은 여러 대의 서버가 데이터베이스를 공유하므로 병목현상이 발생해 더 많은 비용이 발생할 수 있습니다. 특히, Active-Active 방식은 모든 서버가 활성화된 상태이므로 병목 현상이 더 심하게 발생할 수 있습니다. 이러한 단점을 완화시킬 수 있는 방식이 바로 Active-StandBy 방식이다.
  • Active-StandBy 방식은 Active 상태인 서버와 Stand-By 상태인 서버를 나누어 운영한다. 즉, Stand-By 상태의 서버는 말 그대로 준비 상태로 대기하다 Active 서버에 문제가 발생했을 경우 Active 상태로 전환되어 사용된다. 이를 통해, 병목 현상을 해결할 수 있지만, 장애가 발생했을 경우 Stand-By 상태에서 Active 상태로 전환하는 시간동안 서비스를 사용할 수 없다는 단점도 존재한다.

 

10. DB 튜닝이란?

• 데이터베이스 응용, 데이터베이스 자체, 운영체제의 조정 등을 통하여 최적의 자원으로 최적의 성능(응답속도)을 얻을 수 있도록 개선하는 작업입니다.

DB 튜닝은 3단계로 진행됩니다.

1. DB 설계 튜닝
2. DBMS 튜닝
3. SQL 튜닝

튜닝	영역기법	기법 설명
DB 설계 튜닝 영역 (모델링 관점)	테이블 분할 및 통합	파티션 기능, 테이블 수평/수직 분할
	식별자 지정/Key 설정	본질/인조 식별자 정의, 클러스터링
	효율적 인덱스 설정	인덱스 분포도 고려 10~15%(손익 분기점)
	정규화/반정규화	테이블, 컬럼, 관계 정규화/반정규화
	적절한 데이터 타입 선정	조인 시 연결되는 데이터 타입 일치
	데이터 모델링	슈퍼/서브 타입, PK, 파티셔닝, 데이터 통합
DBMS 튜닝 영역 (환경 관점)	I/O 최소화	실제 필요한 데이터만 Read, Query off-loading
	Buffer Pool 튜닝	지역성 관점 데이터 관리, Keep Buffer Cache
	Commit/Check Point	Check Point 수행주기 조절, Commit 주기 조정
	Thread/Reuse	Middleware 기능과 연동
SQL 튜닝 영역 (APP 관점)	Undo Segment 설정	Undo 영역 크기 조정
	옵티마이저	RBO/CBO 이해, 통계정보 최신화
	힌트 사용	지원되는 힌트 기반 실행계획 유도
	부분범위 처리	일부만 Access, 옵티마이저 정보 제공
	인덱스 활용	인덱스 기반 조회 속도 향상, Sort 연산 대체
	조인 방식 / 순서	실행계획(Plan) 확인 후 조정
	동적 SQL 지양	파싱(Parsing) 부하 감소위한 Static SQL 사용
	다중 처리	한 번의 DBMS 호출로 여러 건 동시 처리
	병렬 처리	하나의 SQL을 여러 개의 CPU가 분할 처리
	SORT 튜닝 수행	인덱스 기반 MIN, MAX 구하기, TOP-N 쿼리

 

꼬리 질문

• 인덱스를 잡는 기준은?
• 속도 개선을 위해서 해본 일은?
• 쿼리 튜닝 경험에 대해서 말해보세요.

 

11. Primary Key와 Foreign Key에 대해 설명해 주세요.

• Primary Key(기본 키)는 데이터베이스 테이블에서 각 행(row)을 고유하게 식별하는 열(column) 또는 열의 조합을 말합니다. 키가 소속된 테이블에서 중복되지 않아야 하며, 모든 행은 기본 키 값을 가집니다. 주로 이 키가 식별자(identifier)로 사용됩니다. 각 행을 고유하게 식별하기 때문에 검색, 수정, 삭제, 구분 등의 작업에서 유용하게 사용됩니다.
• Foreign Key(외래 키)는 한 테이블의 열(column)이 다른 테이블의 기본 키(primary key)를 참조하는 역할을 합니다. 다른 테이블과의 관계를 형성하여 데이터간의 일관성과 무결성(Integrity)을 유지하는 것에 사용합니다.

외래 키 제약 조건은 데이터베이스 시스템에서 외래 키 값을 검증하고 관리하는 것에 사용합니다. 조건은 부모 테이블(참조 테이블)의 값과 일치하지 않거나 해당 값이 null 상태일 때도 똑같이 적용됩니다.

 

12. 데드락(Deadlock)에 대해 설명해 주세요.

데드락(Deadlock)은 두 개 이상의 프로세스 또는 스레드가 서로의 자원을 기다리며 무한히 정지 상태에 빠지는 상황을 말합니다. 이 상태에서는 어떠한 프로세스도 작업을 계속할 수 없으며 시스템의 성능과 안정성에 심각한 영향을 미칠 수 있습니다.

 

데드락이 발생하는 4가지 조건 (Coffman 조건)

데드락이 발생하려면 다음 네 가지 조건이 모두 만족되어야 합니다.

1. 상호 배제(Mutual Exclusion)
   • 자원은 한 번에 한 프로세스만 사용할 수 있어야 합니다.
   • 예: 파일, 프린터 등은 동시에 여러 프로세스가 사용할 수 없습니다.
2. 점유 대기(Hold and Wait)
   • 최소한 하나의 자원을 점유하고 있으면서, 추가적인 자원을 요청하며 대기 중인 상태가 있어야 합니다.
   • 예: 스레드 A가 자원 X를 점유한 상태에서 자원 Y를 요청하며 대기.
3. 비선점(Non-preemption)
   • 자원이 점유된 상태에서는 해당 자원을 강제로 빼앗을 수 없어야 합니다.
   • 예: 스레드 B가 자원 Y를 점유한 상태에서는 스레드 A가 Y를 강제로 가져올 수 없음.
4. 순환 대기(Circular Wait)
   • 두 개 이상의 프로세스가 자원을 서로 기다리며 원형 대기를 이루어야 합니다.
   • 예: 스레드 A는 자원 X를 점유하며 자원 Y를 기다리고, 스레드 B는 자원 Y를 점유하며 자원 X를 기다리는 상태.

• 해결 방안: 타임아웃 설정, 트랜잭션 순서 지정, 데이터 락 최소화.

 

13. CHAR와 VARCHAR의 차이점에 대해 설명해 주세요.

1. 고정 길이 vs. 가변 길이
   • CHAR: 항상 고정된 길이로 저장되며, 데이터가 길이보다 짧을 경우 빈 공간에 공백으로 채워짐.
     예: CHAR(10)에 "abc"를 저장하면 실제로 "abc "로 저장됩니다.
   • VARCHAR: 데이터의 실제 길이만큼 저장되며, 길이 정보를 별도로 관리합니다.
     예: VARCHAR(10)에 "abc"를 저장하면 "abc"로만 저장됩니다.
2. 공간 효율성
   • CHAR: 데이터가 짧을수록 불필요한 공백으로 인해 공간 낭비가 발생할 수 있습니다.
   • VARCHAR: 저장 공간을 절약할 수 있지만, 길이를 저장하기 위한 추가 오버헤드(1~2바이트)가 있습니다.
3. 성능 차이
   • CHAR: 고정된 길이로 처리하기 때문에 인덱스 및 검색 성능이 더 빠릅니다.
   • VARCHAR: 가변 길이 데이터 처리로 인해 검색 시 추가 연산이 발생해 약간 느립니다.
4. 패딩(Padding)
   • CHAR: 데이터를 저장할 때 부족한 공간은 공백으로 채워지며, 비교 시에도 공백을 무시합니다.
     예: "abc "와 "abc"는 동일하게 처리됩니다.
   • VARCHAR: 공백 패딩이 없으므로, 저장된 데이터 그대로 비교됩니다.

---

++ 언제 각 자료형을 사용하면 좋을까?

• CHAR 사용 예시
  • 고정된 길이의 데이터 (길이가 항상 일정한 경우): 국가 코드, 전화번호, 우편번호, 성별 등.
  • 읽기 성능이 중요한 경우: 고정 길이로 처리되므로 읽기 작업에서 성능이 더 좋음.
• VARCHAR 사용 예시
  • 가변 길이의 데이터 (길이가 자주 달라지는 경우): 사용자 이름, 이메일 주소, 메모 등.
  • 공간 효율성이 중요한 경우: VARCHAR는 실제 데이터 크기만큼만 저장되므로 디스크 공간 절약에 유리.

 

 

14. VARCHAR vs TEXT 에 대해 설명해보세요.

[MySQL 기준]

varchar 특징:

• 최대 길이를 지정하여 사용(최대 65,535 바이트, 단, 전체 행 크기 제한에 영향을 받음).
• 길이가 가변적이므로 실제 데이터 길이에 따라 저장 공간을 효율적으로 사용.
• 인덱싱 가능: VARCHAR 필드 전체에 대해 인덱스를 설정할 수 있습니다.
• 테이블의 메모리 내 저장 공간(Temporary Table)에 적합.

• 장점:
  • 읽기 및 검색 성능이 상대적으로 빠름.
  • 데이터 길이가 제한되어 있어 메모리 관리가 효율적.
  • 전체 텍스트에 대해 인덱싱 가능.
• 단점:
  • 최대 길이를 미리 지정해야 하며, 예상보다 길이가 작거나 큰 경우 공간 낭비 또는 데이터 손실 가능.

---

text 특징:

• 길이가 매우 긴 문자열 데이터를 저장(TEXT -> 65,535 characters (16KB), LONGTEXT 최대 4GB).
• 데이터는 테이블의 메인 스토리지가 아니라 별도의 테이블 공간에 저장되며, 원래 테이블에는 포인터만 저장됩니다.
• 인덱싱 제한: 기본적으로 TEXT 필드에는 처음 몇 바이트만 인덱싱 가능합니다(예: MySQL의 경우 CREATE INDEX(column_name(255))와 같은 방식).
• 장점:
  • 매우 큰 데이터(예: 블로그 글, 설명 등)를 처리하는 데 적합.
  • 저장 공간을 유연하게 사용할 수 있음.
• 단점:
  • 검색 및 읽기 성능이 상대적으로 느림(별도 저장소 접근 필요).
  • 전체 텍스트에 대해 인덱싱이 불가능하거나 제한적.
  • 임시 테이블에서 사용할 수 없음.

 

---

[postgreSQL 기준]

varchar 특징:

• PostgreSQL에서 VARCHAR(n)는 최대 길이를 지정할 수 있지만, text와 동일한 데이터 구조를 사용합니다.
• 길이 제한을 명시하지 않은 VARCHAR는 사실상 TEXT와 동일한 성능 및 기능을 가집니다.
• 길이 제한이 있는 경우, 데이터 입력 시 길이를 검증합니다.

• 장점:
  • 길이 제한으로 데이터 무결성을 보장.
  • 작은 데이터에 대해 TEXT와 거의 동일한 성능.
• 단점:
  • 길이 제한을 설정한 경우, 길이를 초과하면 오류 발생.

---

text 특징:

• PostgreSQL에서 TEXT는 길이 제한이 없는 문자열 데이터 타입으로, 저장 공간과 데이터 관리에 더 유연합니다.
• TEXT 데이터는 TOAST(The Oversized-Attribute Storage Technique)라는 별도의 메커니즘을 통해 압축 및 분리 저장되어 메모리 효율성을 높입니다.

• 장점:
  • 길이 제한이 없고, 매우 큰 데이터를 저장할 수 있습니다.
  • 데이터가 크더라도 효율적으로 압축 및 저장.
  • 인덱싱 및 풀텍스트 검색에 유리(PostgreSQL의 GIN, GiST 인덱스 활용 가능).
• 단점:
  • 데이터가 클수록 조회 성능이 떨어질 수 있음.

 

14. 트랜잭션 병렬 실행 시 발생하는 문제점

 

트랜잭션 병렬 실행은 데이터베이스의 성능과 동시성을 높이는 데 도움을 주지만, 잘못된 데이터 처리나 데이터 무결성 문제를 초래할 수 있습니다. 아래는 발생할 수 있는 문제들입니다.

문제	발생 원인	결과
Dirty Read	커밋되지 않은 데이터를 읽음	잘못된 데이터 기반으로 작업 수행 (롤백 시 데이터 무효화)
Non-Repeatable Read	다른 트랜잭션이 데이터를 수정 또는 삭제함	동일 데이터 조회 시 값이 다르게 나타남
Phantom Read	다른 트랜잭션이 데이터를 삽입하거나 삭제함	동일 조건으로 조회 시 레코드 수가 달라짐

 

---

트랜잭션 격리 수준과 문제점 해결

데이터베이스는 격리 수준(Isolation Level)을 통해 위 문제를 방지할 수 있습니다. 하지만 높은 격리 수준은 성능 저하를 초래하므로, 적절한 수준을 선택하는 것이 중요합니다.

격리 수준	Dirty Read 방지	Non-Repeatable Read 방지	Phantom Read 방지	특징
Read Uncommitted	X	X	X	성능은 높지만 데이터 무결성이 낮음
Read Committed	O	X	X	커밋된 데이터만 읽음
Repeatable Read	O	O	X	동일 데이터를 반복 조회해도 값이 유지됨
Serializable	O	O	O	가장 높은 수준의 격리, 팬텀 리드 방지 가능

++ 꼬리질문

MySQL InnoDB의 Repeatable Read 격리 수준에서 Non-Repeatable Read와 Phantom Read를 방지할 수 있다고 하는데 어떻게 가능한가?

MVCC는 데이터베이스에서 동시성 제어를 위해 사용되는 기술로, 읽기 및 쓰기 작업이 동시에 이루어질 때 잠금을 최소화하고 일관성 있는 데이터 뷰를 제공하는 방법입니다. 해당 방법을 통해서 phantom read 을 방지할 수 있습니다.

• INSERT 시에는 새로운 데이터 행을 생성하며, 해당 행은 트랜잭션 ID를 포함한 메타데이터와 함께 저장됩니다.
• UPDATE: 기존 행을 덮어쓰지 않고, 새로운 버전을 생성합니다. 이전 행의 정보를 Undo 로그에 기록하여 필요 시 과거 데이터를 복원할 수 있습니다.
• DELETE: 데이터 행을 즉시 삭제하지 않고, 삭제된 것으로 표시합니다. Undo 로그에 기존 데이터를 유지하여 복원이 가능하도록 합니다.
• SELECT: 트랜잭션의 Read View를 기준으로, 트랜잭션이 읽을 수 있는 데이터 버전을 결정합니다. 데이터 수정이 발생하더라도, 트랜잭션 시작 시점의 데이터 상태를 유지합니다.

 

15. 데이터베이스 Lock의 종류에 대해 말해보세요.

• 공유 Lock: 데이터를 읽을 때 사용. 다른 트랜잭션이 읽기는 가능하지만 변경은 불가능.
• 배타적 Lock: 데이터를 변경할 때 사용. 다른 트랜잭션이 읽기 및 변경 모두 불가능.

 

항목	락 (Lock)	격리 수준 (Isolation Level)
정의	데이터 접근 제어 메커니즘	트랜잭션 상호작용 제어 수준

 

++해결 방법

MySQL InnoDB에서의 데드락 관리를 할 수 있습니다.

• MySQL은 Wait-for Graph(트랜잭션 간의 대기 상태를 그래프로 표현하고, 사이클이 발생하면 데드락이라고 판단)를 사용해 데드락을 탐지합니다.
• 데드락 발생 시, 피해자를 선택하고 해당 트랜잭션을 롤백할 수 있습니다.
• 아래와 같이 타임아웃을 설정하여 교착 상태가 계속되지 않도록 대기 시간을 제한할 수 있다.

SET innodb_lock_wait_timeout = 50;

 

16. Commit과 Flush의 차이점에 대해서 설명해 주세요.

커밋은 트랜잭션 완료 후 변경 사항을 DB에 영구적으로 반영하는 것입니다.

Flush는 트랜잭션 동장 중 영속성 콘텍스트의 변경 내용을 데이터베이스에 반영하여 영속성 콘텍스트와 데이터베이스 간의 동기화를 하는 과정입니다. Flush는 트랜잭션이 끝나기 전에 실행되기 때문에, 트랜잭션이 롤백되면 데이터베이스에 반영된 변경 사항도 취소됩니다.

항목	Commit	Flush
목적	트랜잭션을 종료하고 변경 사항을 데이터베이스에 영구적으로 저장	영속성 컨텍스트의 변경 사항을 데이터베이스와 동기화
호출 시점	트랜잭션이 완료될 때 호출	트랜잭션 중간 상태에서도 명시적으로 호출 가능
데이터베이스 반영	변경 사항이 영구적으로 반영되며, ROLLBACK이 불가능	변경 사항이 데이터베이스에 반영되지만, 트랜잭션 내에서는 ROLLBACK이 가능
주요 개념	트랜잭션의 종료와 확정 (완료된 상태)	영속성 컨텍스트와 데이터베이스 간의 동기화 (중간 상태)