한 줄 정의
잠금(Lock) 은 동시성을 제어하고, 트랜잭션 은 데이터 정합성을 보장하며, 격리 수준 은 트랜잭션 간 데이터 공유 범위를 결정합니다.
쉽게 말하면
은행 창구에 비유하면:
- 트랜잭션 은 “입금 + 잔액 업데이트”를 하나의 작업으로 묶어서, 둘 다 성공하거나 둘 다 취소되게 보장하는 것입니다
- 잠금 은 한 고객이 계좌를 수정하는 동안 다른 고객이 같은 계좌를 건드리지 못하게 막는 것입니다
- 격리 수준 은 다른 창구에서 진행 중인 작업을 어디까지 볼 수 있는지 결정하는 정책입니다
왜 중요한가?
이 세 가지 개념을 정확히 이해하지 못하면 실무에서 다음과 같은 문제를 마주하게 됩니다:
- “UPDATE가 왜 이렇게 오래 걸리는가?” → InnoDB의 인덱스 기반 잠금 메커니즘을 모르면 답할 수 없습니다
- “데이터가 갑자기 바뀌었다?” → 격리 수준에 따른 NON-REPEATABLE READ를 모르면 원인을 찾을 수 없습니다
- “트랜잭션 안에서 메일을 보내도 되는가?” → 트랜잭션 범위 최소화 원칙을 모르면 서비스 장애로 이어질 수 있습니다
핵심 내용
5.1 트랜잭션
| 서브노트 | 핵심 주제 | |
|---|---|---|
| Ch05-1 트랜잭션 | InnoDB vs MyISAM 부분 업데이트 문제, 트랜잭션 범위 최소화 |
트랜잭션이 없으면 Partial Update로 인해 쓰레기 데이터가 남고, 이를 수동으로 정리해야 합니다. InnoDB의 트랜잭션은 이런 고민을 원천적으로 제거합니다.
5.2 MySQL 엔진의 잠금
| 서브노트 | 핵심 주제 |
|---|---|
| Ch05-2 MySQL 엔진의 잠금 | 글로벌 락, 백업 락, 테이블 락, 네임드 락, 메타데이터 락 |
MySQL 엔진 레벨의 잠금은 모든 스토리지 엔진에 영향 을 미칩니다. 특히 메타데이터 락은 DDL 작업 시 서비스 영향을 최소화하기 위해 반드시 이해해야 합니다.
5.3 InnoDB 스토리지 엔진 잠금
| 서브노트 | 핵심 주제 |
|---|---|
| Ch05-3 InnoDB 스토리지 엔진 잠금 | 레코드 락, 갭 락, 넥스트 키 락, 자동 증가 락, 인덱스와 잠금 |
InnoDB는 레코드가 아니라 인덱스를 잠급니다. 이 사실 하나가 MySQL에서 인덱스 설계가 중요한 가장 핵심적인 이유입니다.
5.4 MySQL의 격리 수준
| 서브노트 | 핵심 주제 |
|---|---|
| Ch05-4 MySQL의 격리 수준 | READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE |
MySQL의 기본 격리 수준은 REPEATABLE READ이며, InnoDB는 MVCC 덕분에 이 수준에서도 PHANTOM READ가 발생하지 않습니다.
정리
잠금 vs 트랜잭션 vs 격리 수준
| 개념 | 목적 | 범위 |
|---|---|---|
| 트랜잭션 | 데이터 정합성 보장 | 논리적 작업 셋의 원자성 |
| 잠금 | 동시성 제어 | 동일 자원에 대한 순차적 접근 |
| 격리 수준 | 트랜잭션 간 가시성 결정 | 다른 트랜잭션의 변경을 언제 볼 수 있는가 |
MySQL 잠금 계층 구조
flowchart TD subgraph MySQL_Engine["MySQL 엔진 레벨"] GL[글로벌 락] BL[백업 락] TL[테이블 락] NL[네임드 락] ML[메타데이터 락] end subgraph InnoDB_Engine["InnoDB 스토리지 엔진 레벨"] RL[레코드 락] GapL[갭 락] NKL[넥스트 키 락] AIL[자동 증가 락] end MySQL_Engine -->|"모든 스토리지 엔진에 영향"| InnoDB_Engine NKL -->|"= 레코드 락 + 갭 락"| RL NKL --> GapL
내 생각
-
트랜잭션의 범위를 최소화하라는 원칙은 단순히 “짧게 하라”가 아니라, 네트워크 작업(메일 발송, API 호출)을 트랜잭션 밖으로 빼라 는 실질적인 지침입니다. 메일 서버가 응답하지 않으면 DB 커넥션이 고갈되는 장애로 이어질 수 있습니다.
-
InnoDB가 인덱스를 잠근다 는 사실은 반드시 기억해야 합니다. 적절한 인덱스 없이 UPDATE를 실행하면 테이블의 모든 레코드가 잠기게 됩니다. 이것이 MySQL에서 인덱스 설계가 성능뿐 아니라 동시성에도 직결 되는 이유입니다.
관련 개념
- Ch04 아키텍처 — InnoDB의 MVCC, 언두/리두 로그의 동작 원리
- Ch04-2 InnoDB 스토리지 엔진 — 버퍼 풀, 언두 로그, MVCC 상세
- Ch08 인덱스
출처
- Real MySQL 8.0 (1권), Ch05 트랜잭션과 잠금