MySQL 운영 중 lock wait timeout exceeded 에러를 보면 처음에는 꽤 막막합니다. 단순히 한 쿼리가 실패한 것처럼 보이지만, 실제로는 다른 세션이 잠금을 오래 쥐고 있어서 뒤쪽 작업이 줄줄이 밀리는 경우가 많습니다.
이 글에서는 아래 내용을 정리합니다.
- lock wait timeout이 왜 생기는지
- 트랜잭션과 잠금이 어떻게 엮이는지
- 어떤 세션과 쿼리부터 확인해야 하는지
핵심은 lock wait timeout은 실패한 쿼리 하나만 보면 안 되고, 앞단에서 잠금을 오래 잡고 있는 세션을 같이 찾아야 한다는 점입니다.
lock wait timeout은 왜 생길까
보통 한 트랜잭션이 어떤 row나 인덱스 범위에 대한 잠금을 오래 유지하고 있고, 다른 트랜잭션이 같은 자원에 접근하려 할 때 발생합니다.
즉:
- A 트랜잭션이 잠금을 잡고 오래 머무름
- B 트랜잭션이 기다림
- 일정 시간 후 timeout 발생
같은 흐름입니다.
어떤 상황에서 자주 생길까
대표적인 경우는 아래와 같습니다.
- 긴 트랜잭션
- 커밋/롤백 지연
- 같은 row를 자주 갱신하는 핫스팟
- 인덱스가 좋지 않아 잠금 범위가 넓어짐
즉, 단순히 update 쿼리가 많아서만이 아니라, 트랜잭션 구조와 접근 패턴이 함께 문제일 수 있습니다.
먼저 무엇을 확인할까
실무에서는 보통 아래를 먼저 봅니다.
- 어떤 쿼리가 timeout 되었는지 확인
- 그 시점에 잠금을 잡고 있던 세션 찾기
- 오래 열린 트랜잭션 확인
- 문제가 되는 테이블과 쿼리 패턴 파악
중요한 점은 timeout 난 쿼리보다 “앞에서 막고 있던 세션”이 더 핵심일 수 있다는 것입니다.
긴 트랜잭션이 왜 위험할까
트랜잭션이 오래 열려 있으면 잠금도 오래 유지됩니다. 특히 애플리케이션 코드에서 아래 같은 경우를 자주 봅니다.
- 트랜잭션 안에서 외부 API 호출
- 트랜잭션 안에서 많은 로직 수행
- 사용자 입력 대기 중 커밋 지연
이런 패턴은 lock wait timeout을 만들기 쉽습니다.
인덱스도 왜 중요할까
인덱스가 적절하지 않으면 MySQL이 더 넓은 범위를 읽거나 잠글 수 있습니다. 그러면 실제로는 작은 변경만 하려던 쿼리도 더 많은 충돌을 일으킬 수 있습니다.
즉, lock 문제는 트랜잭션 문제이기도 하지만 동시에 접근 경로 문제이기도 합니다.
자주 하는 오해
1. timeout 난 쿼리만 고치면 된다
앞에서 잠금을 오래 잡고 있던 세션을 안 보면 같은 문제가 반복되기 쉽습니다.
2. 트래픽이 많아서 어쩔 수 없다
트랜잭션 길이와 접근 순서만 정리해도 크게 줄어드는 경우가 많습니다.
3. lock 문제는 DB 설정 문제다
설정도 영향은 있지만, 앱 로직과 쿼리 패턴 영향이 훨씬 큰 경우가 많습니다.
FAQ
Q. 가장 먼저 봐야 하는 것은 무엇인가
실패한 쿼리보다 잠금을 오래 쥔 세션과 긴 트랜잭션입니다.
Q. read 쿼리도 영향을 줄 수 있나
트랜잭션 격리 수준과 쿼리 형태에 따라 영향이 있을 수 있습니다.
Q. lock wait timeout을 줄이려면 어디부터 손대야 하나
트랜잭션을 짧게 만들고, 핫스팟 쿼리와 인덱스를 함께 점검하는 것이 좋습니다.
Read Next
- 잠금 이전에 쿼리 성능 자체가 문제라면 MySQL slow query 가이드를 먼저 보는 것이 좋습니다.
- 연결 고갈과 함께 나타난다면 MySQL too many connections 가이드와 같이 보면 흐름이 잘 잡힙니다.
심사 대기 중에는 광고 대신 관련 가이드를 먼저 보여줍니다.
먼저 읽어볼 가이드
검색 유입이 많은 핵심 글부터 이어서 보세요.
- 미들웨어 트러블슈팅 가이드: Redis vs RabbitMQ vs Kafka 개발자를 위한 미들웨어 트러블슈팅 허브 글입니다. Redis, RabbitMQ, Kafka 중 어떤 증상부터 먼저 봐야 하는지와 어떤 문제 패턴이 각 시스템에 가까운지 정리합니다.
- Kubernetes CrashLoopBackOff: 먼저 볼 것들 startup failure, probe, config, resource limit 관점에서 CrashLoopBackOff를 어떻게 나눠서 봐야 하는지 정리한 가이드입니다.
- Kafka consumer lag가 계속 늘 때: 트러블슈팅 가이드 Kafka consumer lag가 계속 늘어날 때 무엇부터 봐야 하는지 정리합니다. poll 주기, 처리 속도, rebalance, consumer 설정까지 실전 기준으로 다룹니다.
- Kafka Rebalancing Too Often 가이드 Kafka consumer group에서 rebalance가 너무 자주 일어날 때 membership flapping, poll timing, protocol, assignment churn을 어떤 순서로 봐야 하는지 설명하는 실전 가이드입니다.
- Docker container가 계속 재시작될 때: 먼저 확인할 것들 exit code, command failure, environment mistake, health check 관점에서 Docker restart loop를 푸는 실전 가이드입니다.
심사 대기 중에는 광고 대신 관련 가이드를 먼저 보여줍니다.