InnoDB에서 행 잠금(row lock)과 MVCC는 어떻게 동작하며, 데드락을 어떻게 피하는가?

Question

IT Interview Practice · Accepted Answer

InnoDB는 두 가지 메커니즘을 결합합니다. **MVCC**는 일반 `SELECT`가 잠금 없이 일관된 스냅샷을 읽게 하므로, 읽기 작업이 쓰기 작업을 절대 블로킹하지 않습니다. **잠금**은 쓰기를 보호합니다: `UPDATE`/`DELETE`/`SELECT ... FOR UPDATE`는 행 잠금을 획득하고, InnoDB는 REPEATABLE READ에서 팬텀을 막기 위해 **넥스트 키 락**(행 + 그 앞의 간격)도 사용합니다.

## 데드락

데드락은 순환입니다: T1이 잠금 A를 쥔 채 B를 원하고, 동시에 T2는 B를 쥔 채 A를 원합니다. 둘 다 진행할 수 없죠. InnoDB는 **순환을 감지하고 한 트랜잭션(비용이 더 싼 희생자)을 롤백**하여 오류 1213을 내고, 나머지 하나가 완료되게 합니다.

```sql
-- T1                              -- T2
BEGIN;                             BEGIN;
UPDATE acct SET bal=bal-1          UPDATE acct SET bal=bal-1
  WHERE id=1;  -- locks row 1        WHERE id=2;  -- locks row 2
UPDATE acct SET bal=bal+1          UPDATE acct SET bal=bal+1
  WHERE id=2;  -- waits for T2        WHERE id=1;  -- waits for T1 => DEADLOCK
-- ERROR 1213: Deadlock found; transaction rolled back
```

## 데드락 피하기

- **일관된 잠금 순서** — 항상 같은 순서로 행을 다루세요(예: id 오름차순). 위 예제가 데드락에 빠지는 이유는 오직 두 트랜잭션이 1→2와 2→1로 잠그기 때문입니다.
- **트랜잭션을 짧게 유지** — 잠금을 늦게 획득하고, 빠르게 커밋하며, 네트워크/사용자 대기 구간에 걸쳐 잠금을 쥐고 있지 마세요.
- **최소한만 잠그기** — `WHERE`에 인덱스를 걸어 InnoDB가 범위나 (인덱스 없이는) 사실상 스캔한 모든 행이 아니라 특정 행만 잠그도록 하세요.
- **1213 발생 시 재시도** — 경합 상황에서 데드락은 정상입니다. 트랜잭션을 애플리케이션 수준의 재시도로 감싸세요.

```sql
SHOW ENGINE INNODB STATUS\G   -- LATEST DETECTED DEADLOCK explains who waited on what
```

## 왜 중요한가

실제 동시성 환경에서 잠금 경합과 데드락은 확장되는 데이터베이스와 멈춰버리는 데이터베이스를 가릅니다. 읽기 작업이 MVCC를 사용해 블로킹되지 않는다는 것, 데드락은 예상되며 재시도할 수 있다는 것, 그리고 일관된 잠금 순서가 대부분의 데드락을 막는다는 것을 아는 것이야말로 시니어 온콜 업무가 요구하는 바입니다.

데드락

데드락 피하기

왜 중요한가

관련 질문