세션 A: row 1 락 보유 → row 2 락 대기
세션 B: row 2 락 보유 → row 1 락 대기

   ┌──────────┐         ┌──────────┐
   │ 세션 A    │  HOLDS  │  row 1   │
   │          │────────▶│          │
   │          │◀────────│          │ WAITS
   └──────────┘         └──────────┘
        │ WAITS              ▲ HOLDS
        ▼                    │
   ┌──────────┐         ┌──────────┐
   │  row 2   │◀────────│ 세션 B    │
   └──────────┘  HOLDS  └──────────┘

SHOW ENGINE INNODB STATUS\G

------------------------
LATEST DETECTED DEADLOCK
------------------------
2026-06-20 02:13:44 0x7f8a
*** (1) TRANSACTION:
TRANSACTION 84211, ACTIVE 6 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s)
UPDATE orders SET status='PAID' WHERE id=2
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 58 page no 4 n bits 80 index PRIMARY of table `shop`.`orders`
trx id 84211 lock_mode X locks rec but not gap waiting

*** (2) TRANSACTION:
TRANSACTION 84210, ACTIVE 9 sec starting index read
UPDATE orders SET status='SHIP' WHERE id=1
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 58 page no 4 n bits 80 index PRIMARY of table `shop`.`orders`
trx id 84210 lock_mode X locks rec but not gap

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 58 page no 4 n bits 80 index PRIMARY of table `shop`.`orders`
trx id 84210 lock_mode X locks rec but not gap waiting

*** WE ROLL BACK TRANSACTION (1)

-- 현재 어떤 트랜잭션이 무슨 락을 들고/기다리는지
SELECT * FROM performance_schema.data_locks;

-- 누가 누구를 기다리는지 (대기 관계)
SELECT * FROM performance_schema.data_lock_waits;

-- 사전 준비
CREATE TABLE orders (
  id INT PRIMARY KEY,
  status VARCHAR(20)
);
INSERT INTO orders VALUES (1,'NEW'), (2,'NEW');

-- 세션 A
BEGIN;
UPDATE orders SET status='SHIP' WHERE id=1;   -- id=1 락 획득

-- 세션 B
BEGIN;
UPDATE orders SET status='SHIP' WHERE id=2;   -- id=2 락 획득

-- 세션 A (id=2를 추가로 잠그려 시도 → 대기)
UPDATE orders SET status='PAID' WHERE id=2;

-- 세션 B (id=1을 추가로 잠그려 시도 → 순환 발생!)
UPDATE orders SET status='PAID' WHERE id=1;
-- ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

-- email에 인덱스가 없는 상태
EXPLAIN UPDATE users SET grade='VIP' WHERE email='[email protected]';
-- type: ALL  → 풀 테이블 스캔. 모든 행에 락이 걸린다!

ALTER TABLE users ADD INDEX idx_email (email);

EXPLAIN UPDATE users SET grade='VIP' WHERE email='[email protected]';
-- type: ref  → 해당 행만 락. 충돌 확률 급감

-- 나쁜 예: 코드마다 제각각
-- A 서비스: id 1 → 2
-- B 서비스: id 2 → 1

-- 좋은 예: 항상 PK 오름차순으로 처리
UPDATE orders SET ... WHERE id IN (1,2) ORDER BY id;

-- 부모를 먼저 잠그는 트랜잭션과 자식 INSERT가 충돌
-- 해결: 비즈니스 로직에서 "부모 → 자식" 접근 순서 일관화
-- 또는 외래키 인덱스 점검 (자식 FK 컬럼 인덱스 필수)
SELECT * FROM information_schema.STATISTICS
WHERE TABLE_NAME='order_items' AND COLUMN_NAME='order_id';

import time
import random
from sqlalchemy.exc import OperationalError

def run_with_retry(session, work, max_retries=3):
    for attempt in range(max_retries):
        try:
            result = work(session)
            session.commit()
            return result
        except OperationalError as e:
            session.rollback()
            # MySQL 데드락 에러코드 1213
            if e.orig.args[0] == 1213 and attempt < max_retries - 1:
                backoff = (2 ** attempt) * 0.1 + random.uniform(0, 0.05)
                time.sleep(backoff)  # 지수 백오프 + 지터
                continue
            raise

@Retryable(
    retryFor = DeadlockLoserDataAccessException.class,
    maxAttempts = 3,
    backoff = @Backoff(delay = 100, multiplier = 2))
@Transactional
public void processOrder(Long orderId) {
    // 데드락 발생 시 자동 재시도
}