데이터베이스와 트랜잭션 심화

트랜잭션은 ‘전부 성공하거나 전부 실패하는’ 작업의 묶음이다. 계좌 이체에서 출금만 되고 입금이 안 되는 일이 없도록, 여러 쿼리를 하나의 단위로 묶는다. 이 보장의 성질을 네 글자로 요약한 것이 ACID다.

격리성을 완벽하게 지키려면 트랜잭션을 한 줄로 세워 실행해야 하지만, 그러면 너무 느리다. 그래서 DB는 ‘어디까지 간섭을 허용할지’를 격리 수준으로 단계화한다. 수준이 낮을수록 빠르지만 이상 현상이 생긴다.

* 표준상 REPEATABLE READ는 phantom을 허용하지만, MySQL InnoDB는 갭 락으로 상당 부분 막는 등 DB 구현마다 실제 동작이 다르다. 쓰는 DB의 기본 수준과 동작을 반드시 확인하자.

여러 요청이 같은 데이터를 동시에 바꾸려 할 때 충돌을 막는 방법은 크게 둘이다. 미리 잠그는 비관적 락과, 일단 진행하고 커밋 시점에 검사하는 낙관적 락이다.

-- 읽을 때 version 같이 조회
SELECT id, stock, version FROM product WHERE id = 1;  -- version = 7

-- 쓸 때 '내가 읽은 버전'을 조건으로 건다
UPDATE product
   SET stock = stock - 1, version = version + 1
 WHERE id = 1 AND version = 7;

-- 영향받은 행이 0이면? 그사이 누군가 먼저 바꾼 것 → 충돌 → 재시도

인덱스는 책 뒤의 ‘찾아보기’와 같다. 없으면 처음부터 끝까지 훑어야(풀 스캔) 하지만, 있으면 정렬된 구조(주로 B-tree)를 타고 바로 원하는 행으로 간다. 느린 조회의 가장 흔한 처방이다.

EXPLAIN SELECT * FROM orders WHERE user_id = 42;

-- type=ALL, rows=1000000  → 풀 스캔 (인덱스 못 탐)
-- 인덱스 추가:
CREATE INDEX idx_orders_user_id ON orders (user_id);

EXPLAIN SELECT * FROM orders WHERE user_id = 42;
-- type=ref, rows=12       → 인덱스로 좁혀 읽음

• 선택도가 낮으면 무용: 값 종류가 적은 컬럼(예: 성별)은 인덱스를 타도 거르는 양이 적어 효과가 약하다.
• 함수·형변환은 인덱스를 깬다: WHERE DATE(created_at) = ...처럼 컬럼을 가공하면 인덱스를 못 탄다. 범위 조건으로 바꿔 쓴다.
• 복합 인덱스는 순서가 중요: (a, b) 인덱스는 a단독·a,b 조회엔 쓰이지만 b 단독 조회엔 잘 안 쓰인다.

ORM을 쓰면 편하지만, 무심코 쓰면 쿼리가 폭발한다. 대표적인 함정이 N+1 문제다. 목록 1번을 조회한 뒤, 각 항목의 연관 데이터를 N번 더 조회해 총 N+1번의 쿼리가 나가는 현상이다.

// 1번: 주문 100건 조회
List<Order> orders = orderRepository.findAll();

// + N번: 각 주문의 회원을 지연 로딩으로 하나씩 조회 (쿼리 100번 추가)
for (Order o : orders) {
  System.out.println(o.getMember().getName()); // 매번 SELECT member ...
}
// 결과: 1 + 100 = 101번의 쿼리