그알것 — 그럼에도 알아야 할 것들
홈질문커뮤니티
로그인
그알것 — 그럼에도 알아야 할 것들

Service

  • 홈
  • 소개
  • 질문
  • 커뮤니티

My

  • 내 워크스페이스
  • 저장한 질문
  • 작성한 답변

Policy

  • 이용약관
  • 개인정보처리방침
  • 문의

© 2026 그알것 · What Still Matters

질문 목록Database
Database

InnoDB의 갭락과 넥스트키 락은 무엇이고, 어떻게 팬텀 리드를 막나요?

실무4/5
설계3/5
인간4/5
기초3/5

면접관의 질문 의도

갭락·넥스트키 락을 단순히 "잠금 종류" 정도로 외워 왔는지, 아니면 팬텀 리드와 실행 계획·인덱스 설계까지 연결할 수 있는지를 가른다.

큐레이션 답변

학습 자료

갭락은 인덱스 레코드 사이의 "빈 구간" 자체를 잠가, 그 구간에 새 행이 INSERT되는 걸 막는 잠금이다. 넥스트키 락은 레코드 락 + 그 앞 갭 락을 묶어서 거는 잠금이다. REPEATABLE READ에서 범위 조건 조회(SELECT ... FOR UPDATE, UPDATE ... WHERE 등)에 넥스트키 락이 걸리면, 같은 트랜잭션에서 재조회해도 새 행이 끼어들지 못해 팬텀 리드가 안 보인다. 잠금 범위는 인덱스를 어떻게 타느냐에 따라 크게 달라지기 때문에, 인덱스 설계가 어긋나면 의도보다 훨씬 넓은 구간이 잠겨 동시성이 뚝 떨어진다.

좋은 답변 구조

  1. 01InnoDB 잠금이 레코드 락·갭락·넥스트키 락으로 나뉜다는 구조를 입력·출력 관점으로 먼저 정리한다
  2. 02갭락이 "빈 구간"을 잠가 새 INSERT를 막는 동작을 단계별로 보여 준다
  3. 03REPEATABLE READ에서 넥스트키 락이 팬텀 리드를 차단하는 시나리오를 구체적으로 풀어 설명한다
  4. 04인덱스가 없거나 잘못 잡혔을 때 잠금 범위가 부풀어 동시성이 떨어지는 한계로 마무리한다

자주 실수하는 포인트

갭락과 레코드 락을 같은 개념으로 섞어 설명한다
넥스트키 락의 동작을 "한 레코드 + 다음 레코드"라고 잘못 외운다
팬텀 리드를 막는 메커니즘을 "스냅샷 격리"로만 설명하고 잠금 측면을 빠뜨린다
인덱스 유무가 잠금 범위에 미치는 영향을 무시하고 "쿼리만 보면 된다"고 단정한다

실무 맥락

  • 범위 조건으로 잔액·재고를 갱신하는 쿼리가 동시 트랜잭션과 자주 부딪히는 백엔드
  • 인덱스가 없는 컬럼으로 UPDATE를 날렸다가 테이블 전체가 잠긴 운영 사고
  • REPEATABLE READ 격리에서 발생한 lock wait timeout을 실행 계획으로 추적하는 디버깅 상황
  • READ COMMITTED로 격리 수준을 낮춰 동시성을 높이는 대신 팬텀 리드를 수용하는 설계 결정

본인 경험에 녹이는 힌트

범위 UPDATE가 의외로 넓게 잠겨 lock wait timeout을 본 경험이 있다면 "실행 계획이 갭락 범위를 정한다"는 일반화로 풀어낼 수 있다

팬텀 리드를 재현해 격리 수준 차이를 검증해 본 경험이 있다면 넥스트키 락의 역할을 사례로 보여 줄 수 있다

인덱스 추가로 잠금 범위가 좁아져 동시성이 회복된 경험이 있다면 인덱스 설계와 잠금의 연결로 일반화할 수 있다

커뮤니티 인기 답변

전체 0개

아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.

관련 꼬리 질문

Q1갭락이 걸리지 않는 격리 수준이나 케이스는 어떤 게 있나요
Q2인덱스가 없는 컬럼으로 UPDATE를 날리면 잠금이 어떻게 동작하나요
Q3넥스트키 락이 성능에 주는 부작용을 줄이려면 어떻게 설계하나요
아직 답을 쓰지 않았어요.
큐레이션 답변과 다른 사람 답변을 보고, 자기 언어로 답을 정리해보면 학습 효과가 가장 큽니다.
목차
  • 01면접관의 질문 의도
  • 02큐레이션 답변
  • 03좋은 답변 구조
  • 04자주 실수하는 포인트
  • 05실무 맥락
  • 06본인 경험에 녹이는 힌트
  • 07커뮤니티 인기 답변준비중
  • 08관련 꼬리 질문