🧩 RDB 공통 원리

PostgreSQL을 알아도, Oracle을 알아도, 결국 매일 부딪히는 문제는 같습니다. "동시에 같은 행을 건드리면 어떻게 되는가", "이 쿼리는 왜 느린가". 이 트랙은 특정 제품이 아니라 모든 관계형 DB가 공유하는 원리를 다룹니다. 락·트랜잭션·격리 수준·조인 알고리즘·튜닝 — 한 번 배우면 어느 DB로 옮겨도 그대로 쓰입니다.

먼저 이 장면부터 — 재고 1개가 사라지는 순간

커리큘럼을 읽기 전에, 이 트랙 전체가 왜 필요한지 보여주는 장면 하나를 봅시다. 재고 10개짜리 상품을 두 사용자가 동시에 1개씩 주문했습니다. 코드에는 버그가 없습니다. 그런데 재고는 8이 아니라 9가 됩니다.

커리큘럼 — 5트랙 16장

앞의 순서대로 읽으면 뒤 장의 발판이 됩니다. 각 카드의 "이 장에서 답하는 질문"이 곧 그 장의 학습 목표입니다.

T1. 기초 — 옵티마이저를 이해하기 위한 전제 기초

3~5장의 튜닝 이야기는 전부 이 세 장 위에 서 있습니다. "인덱스를 타지 않는 이유"를 외우지 않고 설명할 수 있게 만드는 것이 목표입니다.

T2. 트랜잭션과 격리 수준 — 정합성의 뼈대 중급

요청하신 "트랜잭션 / 아이솔레이션 레벨"의 본진입니다. 이상현상 5종을 세션 2개 타임라인으로 직접 재현해 보는 실습이 중심입니다.

T3. 락 — 동시성의 실전 이 트랙의 하이라이트

요청하신 낙관적 락 · 비관적 락 · 분산 락을 각각 한 장씩, 예시 코드와 함께 다룹니다. 앞의 애니메이션이 이 트랙 전체의 예고편입니다.

T4. 실행계획과 조인 — 쿼리는 이렇게 실행된다 중급

요청하신 Nested Loop · Hash Join 등 조인 알고리즘이 여기 있습니다. 실행계획을 읽는 법 → 스캔 방식 → 조인 → 집계 순으로, 플랜 트리를 아래에서 위로 읽어 올라가는 순서입니다.

T5. 튜닝과 안티패턴 — 실무로 내려오기 실전

요청하신 튜닝 기법과 쓰면 안 되는 쿼리가 여기 모입니다. 개별 기법을 나열하기 전에 방법론을 먼저 세웁니다 — 측정 없이 하는 튜닝은 도박이기 때문입니다.

🔐 락 3종 비교 — 지금 바로 고르기

16장을 다 읽기 전에도 쓸 수 있도록, 세 가지 락의 선택 기준을 한 표로 정리했습니다. (9장·10장의 요약)

세 가지가 실제 SQL로는 이렇게 생겼습니다.

-- ❶ 락이 필요 없는 경우 — 원자적 단일 문장이 가장 빠르고 안전하다
UPDATE products
   SET stock = stock - 1
 WHERE id = 1
   AND stock >= 1;   -- 0행이면 재고 부족 → 애플리케이션에서 실패 처리

-- ❷ 비관적 락 — 읽는 순간부터 잠근다 (다른 계산이 끼어야 할 때)
BEGIN;
SELECT stock FROM products WHERE id = 1 FOR UPDATE;  -- 여기서 대기 발생
--   … 검증 로직 …   (이 구간이 길수록 전체 처리량이 떨어진다)
UPDATE products SET stock = 8 WHERE id = 1;
COMMIT;

-- ❸ 낙관적 락 — 락 없이 읽고, 커밋 시점에 version으로 검증
SELECT stock, version FROM products WHERE id = 1;   -- stock=10, version=3
UPDATE products
   SET stock = 9, version = 4
 WHERE id = 1 AND version = 3;   -- 0행 = 누군가 먼저 바꿈 → 재조회 후 재시도

-- ❹ 작업 큐 — 여러 워커가 겹치지 않게 집어간다 (비관적 락의 응용)
SELECT id, payload FROM jobs
 WHERE status = 'ready'
 ORDER BY created_at
 LIMIT 10
   FOR UPDATE SKIP LOCKED;   -- 잠긴 행은 대기 없이 건너뛴다

🧪 격리 수준 × 이상현상 매트릭스

표준(ANSI SQL)이 정의한 것과 실제 제품의 동작은 다릅니다. 아래 표는 표준 기준이고, 벤더 차이는 그 아래 표에서 봅니다.

🔗 조인 알고리즘 3종

같은 JOIN 문법이라도 옵티마이저는 상황에 따라 완전히 다른 알고리즘을 고릅니다. 재생해 보세요.

🚫 쓰면 안 되는 쿼리 — 안티패턴 카탈로그

16장에서 각각을 실행계획과 함께 파헤치지만, 목록만으로도 당장 코드 리뷰에 쓸 수 있습니다. 빈도 × 파급력 순으로 정렬했습니다.

가장 자주 보는 세 가지는 미리 코드로 봐 둡시다.

-- ❌ 1. 딥 페이지네이션 — 100만 행을 읽고 버린 뒤 10행을 준다
SELECT * FROM orders ORDER BY id DESC LIMIT 10 OFFSET 1000000;

-- ✅ 키셋(커서) 페이지네이션 — 마지막으로 본 id부터 10행만 읽는다
SELECT * FROM orders
 WHERE id < 8481920            -- 직전 페이지의 마지막 id
 ORDER BY id DESC LIMIT 10;


-- ❌ 2. 컬럼을 함수로 감싸면 idx(created_at)를 쓸 수 없다
SELECT * FROM orders WHERE DATE(created_at) = '2026-07-28';

-- ✅ 범위 조건으로 바꾸면 인덱스를 그대로 탄다
SELECT * FROM orders
 WHERE created_at >= '2026-07-28'
   AND created_at <  '2026-07-29';


-- ❌ 3. NOT IN 목록에 NULL이 섞이면 결과가 통째로 0행이 된다
SELECT * FROM users
 WHERE id NOT IN (SELECT user_id FROM blacklist);  -- user_id에 NULL 존재 시

-- ✅ NOT EXISTS는 NULL에 안전하고 대개 더 빠르다
SELECT * FROM users u
 WHERE NOT EXISTS (
       SELECT 1 FROM blacklist b WHERE b.user_id = u.id);

📈 SQL 튜닝 방법론 — 순서가 8할

기법을 아무리 많이 알아도 순서가 틀리면 시간만 씁니다. 위에서부터 내려오세요. 아래로 갈수록 비용과 리스크가 커집니다.

🏷 벤더 차이 매트릭스

"공통 원리"를 배웠어도 실무에서는 제품 차이에 걸립니다. 자주 부딪히는 지점만 모았습니다.

✍️ 이해도 체크

🧭 추천 학습 경로

16장을 순서대로 읽는 게 기본이지만, 목적이 뚜렷하다면 아래처럼 골라 읽어도 됩니다.