공유 락과 배타 락의 차이: 읽기와 쓰기를 어떻게 막고 기다리게 할까
빠른 답
- 공유 락은 읽은 행을 보호하는 락에 가깝고, 같은 행에 대한 다른 공유 락은 허용하지만 배타 락은 기다리게 합니다.
- 배타 락은 변경할 행을 독점하는 락에 가깝고, 같은 행에 대한 공유 락과 배타 락 요청을 모두 기다리게 합니다.
- 일반
SELECT와SELECT ... FOR SHARE,SELECT ... FOR UPDATE는 다릅니다. InnoDB의 일반 조회는 보통 MVCC 스냅샷을 읽고 행 락을 잡지 않습니다. - 데드락은 두 트랜잭션이 서로 필요한 락을 이미 상대가 쥐고 있을 때 발생하며, DB가 한쪽을 롤백할 수 있습니다.
목차
한눈에 비교
시간 흐름으로 이해하기
왜 공유 락과 배타 락이 헷갈리는가
공유 락과 배타 락을 단순히 “읽기 락”, “쓰기 락”으로만 외우면 MySQL InnoDB의 실제 동작과 어긋나는 부분이 생깁니다. 특히 일반 SELECT가 항상 공유 락을 잡는다고 생각하면 락 대기 상황을 잘못 해석하기 쉽습니다.
InnoDB의 일반 SELECT는 기본적으로 MVCC 기반의 consistent read입니다. 즉, 현재 행을 잠그기보다 트랜잭션이 볼 수 있는 스냅샷을 읽습니다. 반면 SELECT ... FOR SHARE와 SELECT ... FOR UPDATE는 락킹 읽기입니다. 읽는 행을 기준으로 다른 트랜잭션의 변경이나 다른 락킹 읽기와 충돌할 수 있습니다.
배타 락도 “모든 읽기를 막는다”로 이해하면 부족합니다. 어떤 트랜잭션이 SELECT ... FOR UPDATE로 행을 잡고 있어도, 다른 트랜잭션의 일반 consistent read는 과거 버전을 읽을 수 있습니다. 이때 막히는 것은 보통 같은 행을 변경하려는 쿼리, 또는 같은 행에 락을 걸려는 락킹 읽기입니다.
격리 수준도 함께 봐야 합니다. MySQL InnoDB의 기본 격리 수준인 REPEATABLE READ에서는 트랜잭션 안에서 같은 스냅샷을 반복해서 읽는 흐름이 자주 나타납니다. READ COMMITTED에서는 consistent read마다 더 최신 스냅샷을 읽을 수 있습니다. SERIALIZABLE에서는 일반 SELECT도 공유 next-key lock을 설정할 수 있어 대기 양상이 달라질 수 있습니다.
예제 쿼리와 결과 해석
아래 예시는 계좌 행 하나를 기준으로 공유 락과 배타 락이 어떻게 충돌하는지 보여줍니다. accounts.id가 기본 키이므로 id = 1 조건은 비교적 좁은 범위의 레코드를 대상으로 합니다.
CREATE TABLE accounts (
id BIGINT PRIMARY KEY,
owner_name VARCHAR(50) NOT NULL,
balance INT NOT NULL
) ENGINE = InnoDB;
INSERT INTO accounts (id, owner_name, balance)
VALUES (1, 'kim', 10000), (2, 'lee', 20000);
-- 트랜잭션 A
START TRANSACTION;
SELECT id, balance
FROM accounts
WHERE id = 1
FOR SHARE;
-- 트랜잭션 B: A가 커밋하기 전이면 대기
UPDATE accounts
SET balance = balance - 1000
WHERE id = 1;
트랜잭션 A의 FOR SHARE는 id = 1 행을 읽으면서 공유 락을 잡습니다. 다른 트랜잭션도 같은 행을 FOR SHARE로 읽을 수 있지만, UPDATE에는 배타 락이 필요하므로 트랜잭션 B는 A가 끝날 때까지 기다립니다.
읽은 뒤 같은 행을 변경할 예정이라면 FOR UPDATE가 더 직접적인 표현입니다.
START TRANSACTION;
SELECT id, balance
FROM accounts
WHERE id = 1
FOR UPDATE;
UPDATE accounts
SET balance = balance - 1000
WHERE id = 1
AND balance >= 1000;
COMMIT;
이 흐름에서는 첫 SELECT 시점에 변경 대상 행을 먼저 잠급니다. 잔액 검증, 재고 차감, 쿠폰 사용처럼 “읽고 판단한 뒤 같은 행을 변경”하는 작업에서 중간 끼어들기를 줄이는 데 도움이 됩니다.
다만 모든 재고 차감에 락킹 읽기가 필요한 것은 아닙니다. 검증이 단순하다면 UPDATE products SET stock = stock - 1 WHERE id = 100 AND stock > 0처럼 조건부 단일 갱신으로 처리할 수도 있습니다. 여러 행이나 여러 테이블을 같은 판단 단위로 묶어야 할 때 락킹 읽기의 필요성이 커집니다.
실행 계획과 인덱스가 락 범위를 바꾼다
락 범위는 개발자가 머릿속으로 생각한 WHERE 조건과 항상 같지 않습니다. InnoDB는 락킹 읽기, UPDATE, DELETE를 처리할 때 실행 과정에서 스캔한 인덱스 레코드에 락을 겁니다. 고유 인덱스의 고유 조건으로 한 행을 찾으면 잠금 범위가 좁아지기 쉽지만, 범위 조건이나 비고유 인덱스를 사용하면 gap lock 또는 next-key lock까지 관여할 수 있습니다.
다음처럼 실행 계획을 함께 보면 락 경합의 이유를 좁혀갈 수 있습니다.
mysql> EXPLAIN SELECT id, stock FROM products WHERE id = 100 FOR UPDATE\G
*************************** 1. row ***************************
type: const
possible_keys: PRIMARY
key: PRIMARY
rows: 1
Extra: NULL
mysql> EXPLAIN SELECT id, stock FROM products WHERE status = 'READY' FOR UPDATE\G
*************************** 1. row ***************************
type: ALL
possible_keys: NULL
key: NULL
rows: 100000
Extra: Using where
첫 번째 쿼리는 기본 키로 한 행을 찾으므로 락 경합 범위가 작을 가능성이 큽니다. 두 번째 쿼리는 적절한 인덱스를 쓰지 못하고 전체 스캔을 하므로, 결과 행이 적더라도 처리 과정에서 많은 행과 범위가 경합에 노출될 수 있습니다.
성능을 볼 때는 EXPLAIN의 key, type, rows를 함께 확인하는 편이 좋습니다. type: const나 ref처럼 좁은 접근이면 락 범위도 작게 유지되기 쉽습니다. 반대로 ALL, 큰 rows, 범위 조건, 낮은 선택도의 보조 인덱스는 락 대기와 데드락 가능성을 키울 수 있습니다.
트랜잭션 길이도 중요합니다. 쿼리 자체는 빠르게 끝났더라도 애플리케이션 로직이 트랜잭션을 오래 열어 두면 락은 계속 유지됩니다. 외부 API 호출, 파일 처리, 사용자 입력 대기 같은 작업을 트랜잭션 안에 넣으면 작은 행 락도 큰 장애로 번질 수 있습니다.
대기 시간을 짧게 보고 실패 처리하기
락 대기를 너무 오래 방치하면 애플리케이션 스레드와 커넥션 풀이 같이 묶일 수 있습니다. MySQL에서는 세션 단위로 innodb_lock_wait_timeout을 조정해 행 락 대기를 얼마나 기다릴지 정할 수 있습니다. 데드락 감지와는 별개이며, 오래 기다리는 락 대기를 언제 실패로 볼지 정하는 설정입니다.
SET SESSION innodb_lock_wait_timeout = 5;
START TRANSACTION;
SELECT id, balance
FROM accounts
WHERE id = 1
FOR UPDATE;
이 설정은 현재 세션의 행 락 대기 시간을 5초로 줄입니다. 개발 환경이나 배치 작업에서는 문제를 빨리 드러내는 데 도움이 됩니다. 운영 환경에서는 값이 너무 짧으면 짧은 경합도 실패로 바뀔 수 있으므로, 애플리케이션의 재시도 정책과 함께 봐야 합니다.
애플리케이션 트랜잭션 제한 시간, 쿼리 타임아웃, 커넥션 풀 타임아웃도 같은 방향으로 맞춰야 로그 해석이 쉬워집니다. DB는 50초 기다리는데 애플리케이션은 3초 만에 끊는 식이면, 원인이 DB 락인지 애플리케이션 타임아웃인지 구분하기 어려워집니다.
데드락은 어떤 순서에서 발생하는가
데드락은 락을 많이 써서만 생기지 않습니다. 서로 다른 트랜잭션이 같은 자원을 반대 순서로 잡을 때 자주 발생합니다. 예를 들어 트랜잭션 A는 1번 계좌를 먼저 읽고 2번 계좌를 변경하려 하고, 트랜잭션 B는 2번 계좌를 먼저 읽고 1번 계좌를 변경하려 한다고 보겠습니다.
-- 트랜잭션 A
START TRANSACTION;
SELECT id, balance FROM accounts WHERE id = 1 FOR SHARE;
UPDATE accounts SET balance = balance - 1000 WHERE id = 2;
-- 트랜잭션 B
START TRANSACTION;
SELECT id, balance FROM accounts WHERE id = 2 FOR SHARE;
UPDATE accounts SET balance = balance + 1000 WHERE id = 1;
처음에는 A가 1번 행에 공유 락을 잡고, B가 2번 행에 공유 락을 잡습니다. 이후 A가 2번 행을 변경하려면 B의 공유 락이 풀려야 하고, B가 1번 행을 변경하려면 A의 공유 락이 풀려야 합니다. 서로가 서로의 커밋을 기다리는 순환 대기가 만들어집니다.
이런 경우에는 락 획득 순서를 통일하는 방식이 도움이 됩니다. 여러 계좌를 다룬다면 항상 작은 id부터 큰 id 순서로 잠그는 식입니다. 그래도 데드락을 완전히 없애기는 어렵기 때문에, 데드락이 발생하면 짧은 지연 후 트랜잭션을 재시도할 수 있게 애플리케이션을 설계하는 편이 안정적입니다.
락 대기와 데드락 출력 예시 해석하기
락 대기는 “기다리는 쿼리”와 “막고 있는 쿼리”를 같이 봐야 합니다. MySQL 8.4 기준으로는 sys.innodb_lock_waits, Performance Schema의 data_locks, data_lock_waits를 통해 대기 관계를 확인할 수 있습니다.
아래는 sys.innodb_lock_waits와 애플리케이션에서 볼 수 있는 에러 출력 예시입니다. 실제 컬럼과 표현은 MySQL 버전, 권한, sys 스키마 구성에 따라 조금씩 달라질 수 있습니다.
mysql> SELECT waiting_pid, waiting_query, blocking_pid, blocking_query,
locked_table, locked_index, wait_age
FROM sys.innodb_lock_waits\G
*************************** 1. row ***************************
waiting_pid: 42
waiting_query: UPDATE accounts SET balance = balance - 1000 WHERE id = 1
blocking_pid: 39
blocking_query: SELECT id, balance FROM accounts WHERE id = 1 FOR SHARE
locked_table: `app`.`accounts`
locked_index: PRIMARY
wait_age: 00:00:07
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
waiting_query는 기다리는 쿼리이고, blocking_query는 그 대기를 만들고 있는 쿼리입니다. 위 예시는 accounts.id = 1을 갱신하려는 쿼리가 같은 행을 FOR SHARE로 읽은 트랜잭션 때문에 기다리는 상황입니다. locked_index가 PRIMARY라면 기본 키 레코드 경합으로 볼 수 있습니다.
ERROR 1213은 데드락 감지로 한쪽 트랜잭션이 롤백된 경우에 가깝습니다. 반복된다면 락 획득 순서, 트랜잭션 내 쿼리 순서, 인덱스 선택도를 확인해야 합니다. ERROR 1205는 설정된 시간 안에 락을 얻지 못한 경우입니다. 오래 열린 트랜잭션, 느린 쿼리, 넓은 스캔 범위, 커넥션 풀 고갈을 함께 살펴볼 필요가 있습니다.
버전 기준과 오래된 설명 차이
2026년 4월 기준으로 MySQL 공식 문서는 8.4 LTS와 9.6 Innovation 문서를 함께 제공합니다. 운영 안정성을 기준으로 글을 쓴다면 8.4 LTS 문서를 기준선으로 삼고, Innovation 문서는 새 기능과 변경 가능성을 확인하는 용도로 보는 편이 혼동이 적습니다.
공유 락 문법도 오래된 설명과 현재 설명이 섞여 있습니다. 예전 글에서는 SELECT ... LOCK IN SHARE MODE를 많이 볼 수 있지만, MySQL 8.0 이후 문서에서는 SELECT ... FOR SHARE를 그 대체 문법으로 설명합니다. LOCK IN SHARE MODE는 하위 호환을 위해 남아 있으므로 기존 코드를 곧바로 오류로 볼 필요는 없습니다. 새 코드와 새 문서에서는 FOR SHARE를 기준으로 설명하는 편이 현재 문서 흐름과 잘 맞습니다.
락 진단 테이블도 버전 차이가 큽니다. MySQL 5.7의 INFORMATION_SCHEMA.INNODB_LOCKS, INNODB_LOCK_WAITS는 5.7.14부터 deprecated였고 MySQL 8.0에서 제거되었습니다. 현재 MySQL 8.x 계열에서는 Performance Schema의 data_locks, data_lock_waits와 sys.innodb_lock_waits를 먼저 보는 방식이 문서 기준에 가깝습니다.
관련 1차 문서는 다음을 참고할 수 있습니다.
- MySQL 8.4 Reference Manual, InnoDB Locking Reads: https://dev.mysql.com/doc/refman/8.4/en/innodb-locking-reads.html
- MySQL 8.4 Reference Manual, Locks Set by Different SQL Statements in InnoDB: https://dev.mysql.com/doc/refman/8.4/en/innodb-locks-set.html
- MySQL 8.4 Reference Manual, Using InnoDB Transaction and Locking Information: https://dev.mysql.com/doc/refman/8.4/en/innodb-information-schema-examples.html
- MySQL 8.4 Reference Manual, MySQL Releases: Innovation and LTS: https://dev.mysql.com/doc/refman/8.4/en/mysql-releases.html
- MySQL 5.7 Reference Manual, INFORMATIONSCHEMA INNODBLOCK_WAITS Table: https://dev.mysql.com/doc/refman/5.7/en/information-schema-innodb-lock-waits-table.html
원문 참고
https://www.maeil-mail.kr/question/80
댓글
댓글 쓰기