InnoDB 데드락 분석 및 전체 로깅

명령어

-- Latest deadlock: LATEST DETECTED DEADLOCK section (only the most recent is kept)
SHOW ENGINE INNODB STATUS\G
-- Total deadlock counter
SELECT NAME, COUNT FROM information_schema.INNODB_METRICS WHERE NAME = 'lock_deadlocks';
-- Write every deadlock to the error log (logged at Note level, needs verbosity 3)
SET PERSIST innodb_print_all_deadlocks = ON;
SET PERSIST log_error_verbosity = 3;

하는 일

데드락에 관련된 두 트랜잭션, 각자 보유하고 대기하는 락(인덱스, lock_mode, 레코드), InnoDB가 롤백한 쪽을 보여 준다. 카운터는 빈도를 추적하고 오류 로그는 과거 데드락을 보관한다.

사용 시점

애플리케이션이 1213 'Deadlock found when trying to get lock' 오류를 받거나 데드락 알림이 증가할 때.

주의

LATEST DETECTED DEADLOCK은 마지막 이벤트만 보관하며 재시작 시 사라진다. 'HOLDS THE LOCK(S)' / 'WAITING FOR THIS LOCK TO BE GRANTED' 줄의 인덱스 이름과 lock_mode(X, S, gap, insert intention)가 원인을 설명하고, 'WE ROLL BACK TRANSACTION (n)'이 희생자를 보여 준다. 1213 발생 시 애플리케이션은 트랜잭션 전체를 재시도해야 한다. 근본 해결: 일관된 순서로 행에 접근하고, 트랜잭션을 짧게 유지하며, 적절한 인덱스로 gap 락을 줄이고 필요한 곳에 READ COMMITTED를 사용한다. log_error_verbosity=3은 모든 Note 메시지도 활성화하므로 오류 로그 증가를 주시한다. Innodb_deadlocks 상태 변수는 MySQL Community에 없으므로 카운터는 INNODB_METRICS를 사용한다.