UPDATE로 바뀐 행은 몇 개뿐인데 다른 요청이 오래 기다립니다. 실제 잠금 범위와 보유 시간을 어떻게 확인하나요?

수정한 행 수가 적다는 애플리케이션 로그만으로 잠금 범위가 작다고 판단할 수 없습니다. DB는 조건에 맞는 행을 찾기 위해 넓은 범위를 읽고 잠금을 잡을 수 있으며, 많은 개별 잠금을 더 큰 단위로 승격할 수도 있습니다. 먼저 블로킹 체인에서 누가 대기하고 누가 자원을 보유하는지, 잠금 리소스가 행·키·페이지·테이블 중 무엇인지, 보유 시간이 얼마인지 확인하겠습니다. DBMS마다 잠금 모드와 에스컬레이션 정책이 다르므로 제품 이름 없이 단정하지 않겠습니다.

탐색 범위와 보유 시간을 분리합니다

예를 들어 오래된 작업을 일부 UPDATE하는데 상태와 시간에 맞는 인덱스가 없으면 DB가 많은 행을 스캔할 수 있습니다. 최종적으로 10행만 바뀌더라도 탐색 중 공유·업데이트·배타 잠금의 범위와 순서가 다른 요청을 막을 수 있습니다. SQL Server의 락 에스컬레이션은 다수의 행·키·페이지 잠금을 테이블 수준으로 올릴 수 있고, 설정에 따라 분할된 테이블의 HoBT 수준으로 올릴 수도 있습니다. 행 잠금이 페이지 잠금으로 단계적으로 승격된다는 뜻은 아닙니다. 반면, PostgreSQL은 MVCC와 별도의 row lock·predicate lock을 중심으로 다른 양상을 보이고, MySQL/InnoDB는 인덱스 레코드와 gap/next-key 잠금이 격리 수준에 따라 영향을 줍니다. 같은 ‘UPDATE’라는 문장도 엔진·격리·인덱스에 따라 관찰 결과가 다릅니다.

트랜잭션 안에서 외부 API나 사용자 입력을 기다리면 쿼리 실행 시간은 짧아도 연결과 잠금은 오래 유지됩니다. 대기 시간, 실제 CPU·I/O 시간, 잠금 획득 시간, 트랜잭션 전체 시간을 각각 계측하겠습니다. 데드락은 서로 원형으로 기다리는 문제이고 블로킹은 한 방향 대기로도 생기므로, 대기 그래프와 보유 시간을 다르게 읽어야 합니다.

해법은 범위 축소와 안전한 배치부터 시작합니다

원인이 넓은 탐색이면 상태·시간·식별자 조건에 맞는 인덱스와 SARGable 조건을 검토합니다. 대량 변경이면 결정적인 재시작 키로 작은 배치를 만들고 각 배치의 커밋으로 잠금 보유 시간을 줄일 수 있습니다. 그러나 배치 사이에 다른 요청이 들어오면 전체 작업의 의미가 달라질 수 있으므로, 처리 기준 시각·상태 전이·재시도 규칙을 정해야 합니다. 배치를 단순히 나누면 원자성이 사라질 수 있다는 점도 명시하겠습니다.

잠금 힌트로 행 잠금을 강제하거나 격리 수준을 낮추는 방법은 첫 선택이 아닙니다. 힌트가 실제 엔진에서 유효한지, 메모리·로그·스캔 비용을 늘리지 않는지 확인해야 합니다. 격리를 낮추면 대기는 줄어도 부정확한 읽기나 쓰기 충돌이 허용될 수 있습니다. 검증은 동일 부하에서 블로킹 시간, 데드락, 로그 생성량, 처리량, p99를 비교하고, 취소·예외 때 트랜잭션이 반드시 롤백되는지 확인하겠습니다. ‘몇 행만 변경했다’가 아니라 실제 잠금 생명주기와 접근 경로가 기준입니다.

진단 결과가 인덱스 부재가 아니라 트랜잭션 범위라면 코드에서 연결 획득부터 commit까지의 구간을 줄이는 것이 우선입니다. 대량 배치의 경우 한 배치가 실패했을 때 어디까지 재실행하는지, 중간 커밋으로 부분 완료를 사용자에게 어떻게 표시하는지 정해야 합니다. SQL Server의 에스컬레이션 임계·옵션을 그대로 다른 엔진에 적용하지 않고, PostgreSQL의 row version과 predicate 영향, InnoDB의 next-key 잠금 등 실제 엔진의 대기 리소스를 확인하겠습니다.