🎯 F-lab Java 14주차 학습 커리큘럼

14주차 자료의 모든 토픽을 "데이터 타입 → HA/확장 → SQL 고급" 흐름으로 재배열한 학습 경로.
13주차가 DB 이론과 인덱스 였다면, 14주차는 DB 운영 측면 으로 확장.

• 데이터 타입과 인코딩 (CHAR/VARCHAR, BLOB/TEXT, Collation)
• 고가용성 (HA) (Clustering, Replication, PXC, Backup)
• 데이터 분할 (Sharding, Partitioning)
• SQL 고급 기능 (Trigger, JOIN, VIEW, PROCEDURE)

---

📊 학습 경로 한눈에 보기

[Phase 1] 데이터 타입과 인코딩 (CHAR/VARCHAR, BLOB/TEXT, Collation)
   ↓
[Phase 2] DB Clustering — 고가용성의 시작
   ↓
[Phase 3] Replication과 백업 — Master-Slave + PXC
   ↓
[Phase 4] 데이터 분할 — Sharding과 Partitioning
   ↓
[Phase 5] DELETE/TRUNCATE/DROP과 ROLLBACK 메커니즘
   ↓
[Phase 6] SQL 고급 기능 — Trigger, JOIN, VIEW, PROCEDURE

총 6 Phase × 17 Unit — 단일 주차로 적정 분량.

🔗 1~14주차 흐름 정리

주차	주제	핵심 변화
1주차	OOP·JVM·GC·컬렉션·I/O 개론	자바 큰 그림
2주차	JVM 내부·바이트코드·G1 GC	"어떻게 돌아가나"
3주차	컬렉션·제네릭·함수형	자바 표현력
4주차	멀티스레딩·동시성·Executor	동시성 정복
5주차	Atomic + Spring IoC/DI 입문	자바 → Spring 다리
6주차	테스트 + 웹 인프라 + DB 접근 진화	Spring 실전 환경
7주차	JPA/ORM 입문 + 트랜잭션 추상화	DB 추상화 입문
8주차	프록시의 진화	AOP 메커니즘
9주차	Spring AOP 실전 + 트랜잭션 전파	AOP 실전 활용
10주차	트랜잭션 정리 + 빈 라이프사이클 + 격리 수준	트랜잭션 마무리
11주차	JPA의 정체와 영속성 컨텍스트	JPA 메커니즘 완전 이해
12주차	연관관계 + N+1 등 성능 최적화	JPA 실전 활용
13주차	DB 펀더멘털 - 모델링부터 인덱스까지	DB 본연의 영역 (이론)
14주차 (지금)	DB 운영 - 데이터 타입·HA·확장·SQL 고급	DB 운영의 영역

13주차와 14주차의 관계:

• 13주차 = DB 이론 (정규화·NoSQL·CAP·옵티마이저·인덱스)
• 14주차 = DB 운영 (확장·HA·SQL 고급 도구)
• → DB 영역의 이론 + 운영 두 축 완성

---

🗓️ 권장 학습 일정 (압축 5일)

Day	Phase	학습 목표
1일차	Phase 1	데이터 타입과 Collation
2일차	Phase 2 + 3	Clustering + Replication + PXC
3일차	Phase 4	Sharding + Partitioning
4일차	Phase 5 + 6 (전반)	DELETE/TRUNCATE/DROP + Trigger + JOIN
5일차	Phase 6 (후반) + 종합	VIEW + PROCEDURE + 자기 점검

여유 일정 (7일): Phase 2-3에 +1일 (HA는 그림이 필요함). Phase 6은 직접 쿼리 돌리며 학습 권장.

---

📚 Phase 1 — 데이터 타입과 인코딩

목표: SQL 컬럼 설계의 출발점인 데이터 타입 선택과 문자열 비교 규칙을 잡는다.

Unit 1.1 — CHAR vs VARCHAR (고정 vs 가변)

선수 지식: 6주차 Phase 6 (DB 기초)

핵심 비교 ⭐ :

	CHAR(n)	VARCHAR(n)
길이	고정 길이	가변 길이
짧은 데이터 저장 시	공백으로 채움	실제 길이만
속도	빠름 (특히 짧은 문자열)	약간 느림 (길이 계산 필요)
공간 효율	낮음	높음

예시:

-- CHAR(5)
INSERT INTO test VALUES ('Hi');  
-- 저장: 'Hi   ' (공백 3개 추가, 총 5바이트)

-- VARCHAR(5)
INSERT INTO test VALUES ('Hi');
-- 저장: 'Hi' (실제 2바이트만)

사용 가이드:

✅ CHAR 적합 — 길이가 일정한 데이터:

• 국가 코드: CHAR(2) ('US', 'KR')
• 성별: CHAR(1) ('M', 'F')
• 우편번호: CHAR(5)
• ISO 표준 코드

✅ VARCHAR 적합 — 길이 가변:

• 사용자 이름: VARCHAR(50)
• 이메일: VARCHAR(100)
• 설명 텍스트: VARCHAR(255)

ILIC 적용:

• 운임 코드, 통화 코드 → CHAR
• 고객 이름, 화물 설명 → VARCHAR

자기 점검

• VARCHAR가 약간 느린 이유는? (힌트: 길이 정보 추가 저장)
• CHAR(255)에 'Hi'를 저장하면 디스크 사용은? (힌트: 255바이트)

---

Unit 1.2 — BLOB vs TEXT (이진 vs 문자)

선수 지식: Unit 1.1

핵심 비교 ⭐ :

	BLOB	TEXT
데이터 종류	이진(Binary)	문자(Text)
사용 사례	이미지, 동영상, 파일	긴 글, 댓글, 설명
대소문자	구분(Case-Sensitive)	구분 안 함(기본)
비교 방식	바이트 단위	Collation 규칙
인코딩	없음 (원본 그대로)	UTF-8/ASCII 등
문자열 함수	사용 X	LIKE/CONCAT 가능

예시:

BLOB:

CREATE TABLE files (
    id INT,
    image BLOB  -- 이미지 바이너리
);

TEXT:

CREATE TABLE posts (
    id INT,
    content TEXT  -- 게시글 본문
);

MySQL의 BLOB/TEXT 변형:

• TINYBLOB / TINYTEXT (255 bytes)
• BLOB / TEXT (64KB)
• MEDIUMBLOB / MEDIUMTEXT (16MB)
• LONGBLOB / LONGTEXT (4GB)

실무 권장:

• 이미지/파일은 DB에 저장하지 않는 게 좋음
• → 대신 S3 등 오브젝트 스토리지에 저장
• → DB에는 URL만

ILIC 적용:

• 운임 견적 PDF → S3 저장 + URL을 VARCHAR로
• 화물 설명 긴 텍스트 → TEXT

자기 점검

• 이미지를 DB에 저장하면 어떤 문제? (힌트: 크기 폭증, 백업/복구 부담)
• TEXT 컬럼에 인덱스를 거는 게 가능한가? (힌트: prefix index만)

---

Unit 1.3 — Collation과 대소문자 구분

선수 지식: Unit 1.2

핵심 개념

Collation (정렬 규칙):

"문자열을 비교/정렬 하는 방법을 결정하는 규칙"

MySQL Collation 명명 규칙:

• utf8_general_ci — UTF-8, 일반 비교, case-insensitive (대소문자 무시)
• utf8_bin — UTF-8, 바이너리 비교 (대소문자 구분)
• utf8mb4_unicode_ci — UTF-8 4바이트 (이모지 지원)

TEXT의 기본 동작:

• 기본 Collation = utf8_general_ci 등 → 대소문자 무시

예시:

SELECT * FROM users WHERE name = 'alice';
-- 'Alice', 'ALICE', 'alice' 모두 매칭 (case-insensitive 기본)

대소문자 구분이 필요할 때:

SELECT * FROM users WHERE name COLLATE utf8_bin = 'alice';
-- 'alice' 만 정확히 매칭

또는 BINARY 키워드:

SELECT * FROM users WHERE BINARY name = 'alice';

컬럼 단위로 Collation 지정:

CREATE TABLE users (
    name VARCHAR(50) COLLATE utf8_bin  -- 이 컬럼은 대소문자 구분
);

ILIC 활용:

• 일반 검색 (운임명 등) → 기본 (case-insensitive)
• 사용자 ID, 시스템 코드 → utf8_bin (구분)

자기 점검

• 12주차 영속성 컨텍스트에서 이메일 비교 시 대소문자 처리 어떻게 해야 할까?
• 한국어는 Collation 영향이 있는가? (힌트: 자모 분해 비교 등에 영향)

---

📚 Phase 2 — DB Clustering (고가용성의 시작)

목표: 단일 서버 한계를 넘는 첫 번째 도구인 클러스터링의 본질을 이해한다.

Unit 2.1 — Clustering의 정의와 필요성

선수 지식: 13주차 Phase 5 (Scale-Up vs Scale-Out)

핵심 문제

단일 서버의 위험:

• DB 서버 1대 + DB 1개 운영
• 서버 다운 → 서비스 전체 중단
• → 가용성(Availability) 보장 불가

Clustering의 해결:

"여러 서버가 동일한 논리적 데이터베이스를 분산 운영"

핵심 의미:

• 물리적으로 N대 서버
• 논리적으로 1개 데이터베이스 (공유 또는 복제)
• 한 대가 다운돼도 나머지가 정상 동작

구조 (DB 서버 2대 시):

[Client]
    ↓
[Load Balancer]
   /        \
[DB Server 1] [DB Server 2]
   ↓               ↓
[DB Storage]  [DB Storage]
(physically separate)

이점:

• 고가용성 (HA) — 장애 시 서비스 지속
• 부하 분산 — 트래픽을 여러 서버로
• 점진 복구 — 운영 중에도 한 대씩 복구 가능

자기 점검

• 13주차 Scale-Out과 Clustering의 관계는? (힌트: Clustering은 Scale-Out의 한 형태)
• Clustering이 항상 좋은가? (힌트: 비용, 복잡성)

---

Unit 2.2 — Active-Active vs Active-Standby ⭐

선수 지식: Unit 2.1

핵심 2가지 패턴:

Active-Active (동시 운영):

• 모든 서버가 동시에 활성
• 한 대 다운돼도 나머지가 즉시 처리
• 부하를 N개로 분산 → CPU/Memory 부하 ↓

장점:

• 즉각 장애 대응 (Failover 불필요)
• 부하 분산 효과
• 자원 효율

단점:

• 여러 서버가 같은 스토리지 공유 시 병목 가능
• 복잡한 동시성 제어
• 비용 ↑

---

Active-Standby (대기 모드):

• Active 서버만 운영, Standby는 대기
• Active 장애 시 → Failover로 Standby가 Active 전환

장점:

• 비용 ↓ (Standby는 평소 미사용)
• 단순한 구조
• 동시성 충돌 없음

단점:

• Failover 시간 동안 서비스 중단
• 효율은 Active-Active의 절반
• Standby가 Active로 전환 시 부하 처리 가능 검증 필요

---

비교 매트릭스:

	Active-Active	Active-Standby
자원 사용	모두 활성	절반만 활성
Failover 시간	거의 0	수 초 ~ 분
비용	높음	낮음
복잡도	높음	낮음

ILIC 시나리오:

• 핵심 결제 시스템 → Active-Active 권장
• 백오피스/관리 시스템 → Active-Standby 가능

자기 점검

• ILIC가 Active-Standby로 운영 중 Active 다운 시 사용자가 느끼는 영향은?
• Active-Active에서 같은 행을 두 서버가 동시 수정하면? (힌트: 충돌 해결 메커니즘 필요)

---

Unit 2.3 — Quorum과 클러스터 노드 수 (★ 면접 단골)

선수 지식: Unit 2.2

핵심 원리

클러스터 투표 (Quorum):

"노드 일부가 다운되었을 때 나머지가 다수(majority)를 차지하는지 판단"

과반수 룰 ⭐ :

• 과반수 (>50%) 이상의 노드 살아있으면 → 정상 운영
• 그렇지 않으면 → 자동 중단 (Fail-Safe)

왜 필요한가:

• Split Brain 방지 — 네트워크 단절로 클러스터가 둘로 나뉘면 양쪽이 모두 자기를 정상이라 주장 → 데이터 불일치
• 한쪽만 정상으로 인정해야 일관성 유지

예시 (3노드 클러스터):

• 3개 노드 중 2개 살아있음 → 과반수 → 정상 운영
• 2개 노드 다운, 1개만 남음 → 과반수 X → 자동 중단

핵심 통찰 ⭐ :

"클러스터링은 최소 3개 노드 권장 — 1개 다운 시 2개로 정상 운영 가능"

2노드의 위험:

• 1개 다운 → 1개만 남음 → 과반수 X
• → 결국 1노드와 동일

홀수 노드 권장:

• 3, 5, 7개 → 명확한 과반수 가능
• 4, 6개 → 50:50 분리 가능

---

Quorum의 응용:

• MongoDB Replica Set
• Apache ZooKeeper
• Kubernetes etcd
• → 모두 홀수 노드 권장

ILIC 적용:

• 클러스터링 도입 시 → 3노드 시작
• 트래픽 폭증 시 → 5노드로 확장 (4가 아닌)

자기 점검

• "Split Brain"이 발생하면 어떤 사고가? (힌트: 양쪽 클러스터에 다른 쓰기 → 일관성 깨짐)
• 2노드 클러스터의 가용성은 1노드보다 정말 높은가? (힌트: NO — Quorum 룰 때문)

---

📚 Phase 3 — Replication과 백업

목표: Master-Slave 구조와 클러스터링의 차이를 명확히 잡고, PXC와 백업 전략을 본다.

Unit 3.1 — Replication (Master-Slave 복제)

선수 지식: Phase 2, 13주차 Phase 5

핵심 구조

Replication:

"Master 서버의 변경을 Slave 서버로 복제"

구조:

[Master DB] ──복제──> [Slave DB 1]
    ↓                    ↑
 (Write)              (Read only)
                         ↓
                      [Slave DB 2]

역할 분리:

• Master: INSERT, UPDATE, DELETE
• Slave: SELECT 전담

얻는 이점 ⭐ :

1. 읽기 부하 분산

   • Read 트래픽이 압도적으로 많은 시스템
   • Slave를 추가해서 Read 처리

2. Master 부하 ↓

   • Master는 Write만 담당
   • 복잡한 SELECT 쿼리는 Slave로

3. 백업·분석 부하 격리

   • Slave에서 백업·통계 → Master 영향 없음

복제 방식:

• 비동기 (Asynchronous) — 기본, 약간의 지연 허용
• 반동기 (Semi-synchronous) — Slave 하나라도 적용 확인 후 응답
• 동기 (Synchronous) — 모든 Slave 적용 후 응답 (느림)

복제 지연 (Replication Lag):

• 비동기 시 Slave가 Master보다 약간 느림
• 갓 INSERT한 데이터를 Slave에서 SELECT하면 못 찾을 수 있음
• → 일관성 중요한 조회는 Master에서

---

Master/Slave 성능 고려:

• Master와 Slave 성능 비슷 → 복제 지연 없음
• Slave는 Read만이므로 동등 성능 불필요
• 그러나 Failover 시 Slave가 Master 역할 → 성능 차이 크면 위험

ILIC 시나리오:

• 운임 견적 등록 → Master
• 운임 검색 → Slave (Read Replica)
• 야간 통계 → 별도 Slave

자기 점검

• 복제 지연이 사용자에게 어떻게 보일까? (힌트: 등록 후 즉시 조회 시 안 보임)
• Read-after-Write 일관성을 위한 해결책은? (힌트: 명시적으로 Master에서 조회)

---

Unit 3.2 — Replication vs Cluster (★ 면접 단골)

선수 지식: Phase 2, Unit 3.1

핵심 차이 ⭐ :

	Replication	Clustering
구조	Master → Slave (단방향)	모든 노드 동등
Write	Master만	모든 노드 가능
Read	Slave 분산	모든 노드
일관성	비동기 (지연 가능)	동기 또는 즉시
Failover	수동/반자동	자동
주 목적	읽기 성능 + 백업	고가용성 + 즉시 Failover

시각적 비교:

Replication:

[Master]  ─wirte─> Master 자신
   │
   │ 비동기 복제
   ↓
[Slave 1]  ─read 만─
[Slave 2]  ─read 만─

Clustering (Active-Active):

[Node 1] ↔ [Node 2] ↔ [Node 3]
   ↓          ↓           ↓
모두 read/write 가능 (동기 동기화)

---

선택 기준:

Replication 적합:

• 읽기 비율 압도적 (예: 90% read)
• 백업·분석 격리 필요
• 비용 절감

Clustering 적합:

• 즉시 Failover 필수
• 쓰기 부하도 분산 필요
• 강한 일관성

둘 다 사용 가능 (실무 표준):

• 핵심 클러스터(Master) + 읽기 Replica 추가

ILIC 시나리오:

• 운임 시스템 핵심 → Cluster
• 운임 검색 캐시용 → Read Replica

자기 점검

• "Replication은 HA 솔루션인가?"의 답은? (힌트: 부분적, Cluster가 진짜 HA)
• Failover 자동화는 어느 쪽이 강한가?

---

Unit 3.3 — Percona XtraDB Cluster + 백업

선수 지식: Unit 3.2

Percona XtraDB Cluster (PXC) ⭐ :

"MySQL 호환 Active-Active 클러스터링 솔루션"

왜 PXC를 선택하는가:

Replication의 한계:
1. Slave가 Read만 담당 → 성능 좋은 Master 의존
2. Master 장애 시 Slave 자동 승격 X
3. Slave 성능을 낮게 잡으면 Master 대체 어려움

PXC의 해결:

• 모든 노드가 Read/Write 가능
• 한 노드 장애 시 자동으로 다른 노드 활용
• 동기 복제로 강한 일관성

Galera Cluster 기반:

• PXC는 Galera Cluster 기술 사용
• 인증 기반 동기 복제 (Certification-Based Replication)

ILIC 적용 가능성:

• 운임 시스템 핵심 → PXC
• 단, 모든 노드 동시 활성이라 비용 ↑

---

XtraBackup vs mysqldump (백업 도구):

	XtraBackup	mysqldump
방식	Hot Backup (서비스 중)	Logical (SQL 추출)
속도	매우 빠름	느림
결과물	바이너리 파일	SQL 텍스트
복구	빠름	느림 (재실행)
운영 영향	최소	락 발생 가능
도구	Percona 도구	MySQL 기본
적합	대용량 운영 DB	작은 DB, 마이그레이션

XtraBackup 권장:

• 100GB+ 데이터베이스
• 24/7 서비스 (다운타임 불가)

mysqldump 권장:

• 개발/테스트 환경
• 작은 DB
• 다른 DB로 마이그레이션 (SQL 호환성)

ILIC 시나리오:

• 일일 운영 백업 → XtraBackup
• 마이그레이션 / 임시 백업 → mysqldump

자기 점검

• "Hot Backup"의 의미는? (힌트: 서비스 중단 없이 백업)
• mysqldump를 운영 시간에 돌리면? (힌트: LOCK + 성능 저하)

---

📚 Phase 4 — 데이터 분할 (Sharding과 Partitioning)

목표: 한 테이블/한 DB가 너무 커졌을 때의 두 가지 분할 전략을 비교한다.

Unit 4.1 — Sharding (수평 분할)

선수 지식: 13주차 Phase 5 (NoSQL의 Sharding)

핵심 개념

Sharding:

"여러 DB 서버로 데이터를 분할 — 각 서버가 일부 데이터만 가짐"

구조:

[Shard 1: user_id 1~1000만]
[Shard 2: user_id 1000만~2000만]
[Shard 3: user_id 2000만~3000만]

샤드 키 (Shard Key):

• 데이터를 분할하는 기준 컬럼
• 예: user_id, region, hash(id)

샤딩 전략:

1. Range-based (범위):

   • user_id 1~1000만 → Shard 1
   • 장점: 단순
   • 단점: 핫스팟 가능 (특정 범위 집중)

2. Hash-based (해시):

   • hash(user_id) % N → Shard 번호
   • 장점: 균등 분산
   • 단점: 범위 검색 어려움

3. Geographic (지리):

   • 한국 사용자 → Shard 1 (서울)
   • 미국 사용자 → Shard 2 (캘리포니아)
   • 장점: 지연 시간 ↓

---

Sharding의 어려움 ⭐ :

1. JOIN 어려움:

   • 다른 Shard의 데이터를 JOIN 못 함
   • → 애플리케이션에서 JOIN 처리

2. 트랜잭션 분산:

   • 여러 Shard 걸친 트랜잭션 어려움
   • → 분산 트랜잭션 (2PC, Saga)

3. 재샤딩 비용:

   • Shard 추가 시 데이터 재분배
   • 운영 중 큰 부담

4. 샤드 키 선택의 어려움:

   • 잘못 고르면 핫스팟 발생

NoSQL과의 자연스러운 궁합:

• NoSQL은 JOIN 안 씀 → Sharding 친화적
• → 13주차 Phase 5의 Scale-Out 핵심

ILIC 적용 시 검토:

• 102 테이블이 정말 한 DB로 부족한지 먼저 검증
• 보통 수직 확장(Scale-Up) + Replica로 충분
• Sharding은 정말 마지막 카드

자기 점검

• 운임 견적 1억 건이 되면 Sharding이 답인가? (힌트: 먼저 Partitioning 검토)
• 핫스팟 사례를 들어보라 (힌트: 인기 상품, VIP 고객)

---

Unit 4.2 — Partitioning (단일 DB 내 분할)

선수 지식: Unit 4.1

핵심 차이 ⭐ :

	Partitioning	Sharding
분할 단위	단일 DB 내 테이블	여러 DB 서버
위치	한 DBMS	분산 시스템
관리	DBMS 자동	애플리케이션
트랜잭션	정상	분산 어려움
복잡도	낮음	높음

Partitioning의 본질:

"한 테이블을 여러 물리적 조각으로 분할 — DBMS가 자동 라우팅"

---

Partition 종류:

1. Range Partitioning (범위):

CREATE TABLE sales (
    sale_date DATE,
    amount DECIMAL
)
PARTITION BY RANGE (YEAR(sale_date)) (
    PARTITION p2023 VALUES LESS THAN (2024),
    PARTITION p2024 VALUES LESS THAN (2025),
    PARTITION p2025 VALUES LESS THAN (2026)
);

2. List Partitioning (목록):

PARTITION BY LIST (region) (
    PARTITION p_kr VALUES IN ('SEOUL', 'BUSAN'),
    PARTITION p_us VALUES IN ('NY', 'LA')
);

3. Hash Partitioning (해시):

PARTITION BY HASH (user_id) PARTITIONS 4;
-- 4개 파티션으로 균등 분산

4. Key Partitioning:

• Hash와 유사, MySQL 자체 함수 사용

---

Partitioning의 효과:

1. 쿼리 성능 ↑:

   • WHERE 조건이 파티션 키와 일치 → 해당 파티션만 스캔 (Partition Pruning)
   • 예: WHERE sale_date = '2024-...' → p2024 파티션만 조회

2. 관리 용이:

   • 오래된 파티션 → DROP으로 빠른 삭제
   • DELETE는 느리지만 DROP PARTITION은 즉시

3. 인덱스 부담 ↓:

   • 파티션별 인덱스 → 작은 트리 → 빠른 검색

ILIC 적용 가능:

• 일별 트랜잭션 로그 → Range Partitioning by date
• 지역별 운임 → List Partitioning

Partitioning 우선, Sharding은 마지막:

• 1억 행 → Partitioning으로 충분
• 100억 행, 단일 서버 한계 → Sharding 검토

자기 점검

• Partitioning과 인덱스의 관계는? (힌트: 파티셔닝은 인덱스 + α 효과)
• 오래된 데이터 정리에 Partitioning이 효과적인 이유는? (힌트: DROP PARTITION 즉시)

---

📚 Phase 5 — DELETE/TRUNCATE/DROP과 ROLLBACK 메커니즘

목표: 자주 헷갈리는 데이터 삭제 명령의 차이와 ROLLBACK 가능 여부의 본질을 이해한다.

Unit 5.1 — DELETE vs TRUNCATE vs DROP (★ 면접 단골)

선수 지식: 6주차 Phase 6, 10주차 Phase 5

핵심 비교 ⭐ :

	DELETE	TRUNCATE	DROP
분류	DML	DDL	DDL
대상	특정 행	모든 행	테이블 자체
WHERE 절	가능	불가	불가
속도	느림	빠름	즉시
ROLLBACK	가능 ✅	불가 ❌	불가 ❌
AUTO_INCREMENT	유지	초기화	(테이블 사라짐)
인덱스/제약조건	유지	유지	삭제
트리거 발동	✅	❌	❌

---

DELETE — 안전한 삭제:

DELETE FROM users WHERE id = 5;
DELETE FROM users WHERE created_at < '2020-01-01';

-- ROLLBACK 가능
START TRANSACTION;
DELETE FROM users WHERE id = 5;
ROLLBACK;  -- 복구됨

왜 느린가:

• 행마다 개별 삭제
• 트리거 발동
• UNDO LOG 작성 (롤백용)

---

TRUNCATE — 빠른 전체 삭제:

TRUNCATE TABLE users;
-- 모든 행 삭제 (구조는 유지)

왜 빠른가:

• 행 단위가 아닌 테이블 재생성 방식
• UNDO LOG 안 씀 → ROLLBACK 불가

주의:

• AUTO_INCREMENT 초기화 → ID 1부터 다시 시작
• 외래키 참조 시 실패 가능

---

DROP — 완전 제거:

DROP TABLE users;
-- 테이블 + 데이터 + 인덱스 + 제약조건 + 트리거 모두 삭제

복구 불가:

• 백업 없으면 끝
• 운영에서는 매우 신중하게

---

언제 무엇을?:

상황	명령
일부 데이터 삭제	DELETE
모든 데이터 삭제 (테이블 유지)	TRUNCATE
테이블 자체 제거	DROP
트랜잭션으로 안전하게	DELETE

ILIC 시나리오:

• 사용자가 운임 견적 취소 → DELETE
• 테스트 데이터 초기화 → TRUNCATE
• 더 이상 안 쓰는 임시 테이블 → DROP

자기 점검

• TRUNCATE는 트랜잭션 안에서 ROLLBACK 가능한가? (힌트: NO — DDL이라 자동 커밋)
• DELETE 후 AUTO_INCREMENT 값은? (힌트: 유지 — 다음 ID는 그 다음부터)

---

Unit 5.2 — ROLLBACK과 UNDO LOG

선수 지식: Unit 5.1, 6주차 Phase 6 (ACID)

핵심 메커니즘

ROLLBACK이 가능한 이유:

"UNDO LOG 덕분"

UNDO LOG:

• 트랜잭션이 변경한 이전 상태를 저장
• 변경 전의 값(Before Image) 기록
• ROLLBACK 시 이전 상태로 복원

예시 흐름:

1. UPDATE users SET age = 30 WHERE id = 1;
   (age는 원래 25였음)

2. UNDO LOG 기록: "id=1의 age를 25로 되돌릴 것"

3. ROLLBACK 호출
   → UNDO LOG 적용
   → age = 25 복구

---

InnoDB의 두 로그 ⭐ :

	UNDO LOG	REDO LOG
목적	ROLLBACK 지원	복구 (Crash Recovery)
시점	트랜잭션 중	변경 즉시
내용	이전 상태 (Before)	변경 후 (After)
용도	롤백·MVCC	Durability 보장

MVCC (Multi-Version Concurrency Control):

• 10주차 Phase 5의 격리 수준에서 본 개념
• UNDO LOG의 이전 버전 활용 → 다른 트랜잭션이 일관된 스냅샷 조회

---

TRUNCATE는 왜 ROLLBACK 안 되나:

• DDL은 자동 커밋 (Auto-commit)
• UNDO LOG 작성 안 함
• 빠르지만 위험

DELETE의 비용:

• 모든 변경에 UNDO LOG 작성
• → 100만 행 DELETE 시 UNDO LOG도 100만 건
• → 디스크 공간 + 성능 부담

---

ILIC 적용:

• 일반 비즈니스 작업 → DELETE + 트랜잭션 (안전)
• 대량 정리 작업 → TRUNCATE (빠름, 단 백업 후)
• 운영 중 절대 사용 X → DROP

자기 점검

• ROLLBACK이 무한정 가능한가? (힌트: NO — UNDO LOG에 시간/공간 한계)
• 11주차 변경 감지(Dirty Checking)는 UNDO LOG와 같은가? (힌트: 다름 — JPA는 메모리, UNDO는 DB)

---

📚 Phase 6 — SQL 고급 기능

목표: Trigger·JOIN·VIEW·PROCEDURE 등 SQL의 도구함을 정리한다.

Unit 6.1 — Trigger (자동 실행 코드)

선수 지식: Phase 5

핵심 개념

Trigger:

"INSERT/UPDATE/DELETE 시 자동으로 실행되는 코드"

예시 — 학생 삭제 시 이력 보관:

CREATE TRIGGER trg_student_delete
AFTER DELETE ON students
FOR EACH ROW
BEGIN
    INSERT INTO deleted_students (id, name, deleted_at)
    VALUES (OLD.id, OLD.name, NOW());
END;

작동:

DELETE FROM students WHERE id = 5;
-- → 자동으로 deleted_students에 INSERT

---

트리거 종류:

시점:

• BEFORE — 작업 전 실행
• AFTER — 작업 후 실행

이벤트:

• INSERT / UPDATE / DELETE

범위:

• FOR EACH ROW — 행마다
• FOR EACH STATEMENT — 명령마다 (MySQL 미지원)

---

활용 사례 ⭐ :

1. 감사 로그 (Audit Trail) — 변경 이력 추적
2. 데이터 무결성 — 복잡한 검증
3. 자동 계산 — 합계 자동 갱신
4. 알림 — 특정 조건 만족 시 알림 트리거

ILIC 활용 가능성:

• 운임 견적 변경 이력 자동 기록
• 사용자 정보 변경 시 감사 로그
• → 11-12주차 ILIC의 2-layer history 시스템 (Spring AOP 활용)이 트리거의 대안

---

Trigger의 단점 ⚠️ :

1. 숨겨진 동작 — 코드만 봐서는 알 수 없음
2. 디버깅 어려움 — 흐름 추적 곤란
3. 성능 부담 — 대량 작업 시 누적
4. 테스트 어려움 — 단위 테스트 불가

실무 권장:

• 간단한 감사 로그 외에는 트리거 지양
• 복잡한 비즈니스 로직 → 애플리케이션 레이어
• Spring AOP가 더 좋은 대안 (8-9주차)

자기 점검

• Trigger와 Spring AOP의 비교 — 같은 기능을 어디서 구현하는 게 좋을까?
• ILIC의 변경 이력 시스템을 트리거 vs AOP 중 무엇으로 했고 왜?

---

Unit 6.2 — INNER JOIN vs OUTER JOIN ⭐

선수 지식: 6주차 Phase 6 (JOIN)

핵심 개념

JOIN의 본질:

"두 개 이상 테이블을 결합하여 데이터 조회"

INNER JOIN — 매칭만 포함:

SELECT u.name, o.product
FROM users u
INNER JOIN orders o ON u.id = o.user_id;

→ users와 orders 양쪽 모두에 매칭되는 행만 반환
→ 매칭 안 되는 user는 결과에서 빠짐

---

OUTER JOIN — 모든 행 포함:

LEFT OUTER JOIN (왼쪽 기준):

SELECT u.name, o.product
FROM users u
LEFT JOIN orders o ON u.id = o.user_id;

→ users 모든 행 포함
→ orders 없는 user는 NULL로 채워짐

RIGHT OUTER JOIN (오른쪽 기준):

FROM users u
RIGHT JOIN orders o ON u.id = o.user_id;

→ orders 모든 행 포함

FULL OUTER JOIN (양쪽 모두):

-- MySQL은 기본 미지원, UNION으로 시뮬레이션
SELECT * FROM A LEFT JOIN B ON ...
UNION
SELECT * FROM A RIGHT JOIN B ON ...;

→ 양쪽 모든 행, 매칭 안 되면 NULL

---

시각적 비교:

[INNER]
A ∩ B (교집합만)

[LEFT OUTER]
A 전체 + (B에서 매칭되는 부분)

[RIGHT OUTER]
B 전체 + (A에서 매칭되는 부분)

[FULL OUTER]
A ∪ B (합집합)

---

언제 무엇을?:

상황	JOIN 종류
양쪽 모두 있는 행만	INNER
왼쪽 모두 + 매칭	LEFT
한 쪽이 없어도 모두	OUTER
매칭 안 되는 행 찾기	LEFT + WHERE B IS NULL

ILIC 시나리오:

• 주문이 있는 사용자만 → INNER
• 모든 사용자 + 주문 (없으면 0) → LEFT
• 주문 안 한 사용자 찾기 → LEFT + IS NULL

---

JPA에서의 JOIN:

• 12주차 Phase 9 — JOIN, FETCH JOIN
• JPQL 기본은 INNER
• LEFT 명시: LEFT JOIN

자기 점검

• LEFT JOIN과 LEFT OUTER JOIN은 다른가? (힌트: 같음 — OUTER는 생략 가능)
• INNER JOIN으로 매칭 없는 행을 찾을 수 있나? (힌트: NO — LEFT + IS NULL 필요)

---

Unit 6.3 — VIEW (가상 테이블)

선수 지식: Unit 6.2

핵심 개념

VIEW:

"실제 데이터를 저장하지 않는 가상 테이블 — 쿼리 결과를 정의"

예시:

CREATE VIEW user_orders AS
SELECT users.id, users.name, orders.product
FROM users
INNER JOIN orders ON users.id = orders.user_id;

사용:

SELECT * FROM user_orders;  -- 테이블처럼!

---

VIEW의 활용:

1. 복잡한 쿼리 단순화:

   -- 복잡한 JOIN을 한 번 정의 후 재사용
   SELECT * FROM monthly_sales_summary;

2. 보안:

   CREATE VIEW public_users AS
   SELECT id, name FROM users;  -- email, password 제외

3. 권한 분리:

   • 사용자에게 테이블 직접 접근 X
   • VIEW만 SELECT 권한 부여

4. 레거시 호환:

   • 테이블 구조 변경 시 VIEW로 이전 인터페이스 유지

---

VIEW의 한계 ⚠️ :

1. 성능 — 단순 쿼리지만 매번 원본 쿼리 실행
2. 수정 제약 — 복잡한 VIEW는 INSERT/UPDATE 불가
3. 인덱스 X — VIEW 자체에 인덱스 못 검 (Materialized View 제외)

Materialized View (참고):

• 결과를 실제 저장하는 VIEW
• 빠른 조회, 그러나 데이터 갱신 필요
• MySQL 미지원, PostgreSQL/Oracle 지원

ILIC 적용:

• 복잡한 운임 통계 쿼리 → VIEW로 캡슐화
• 보고서용 데이터 → VIEW

자기 점검

• VIEW를 자주 쓰면 어떤 문제? (힌트: 옵티마이저 어려움, 성능)
• VIEW에 INSERT가 가능한 경우는? (힌트: 단순 단일 테이블 VIEW)

---

Unit 6.4 — PROCEDURE (저장 프로시저)

선수 지식: Unit 6.3

핵심 개념

PROCEDURE (Stored Procedure):

"매개변수를 활용하여 정의한 작업을 DB에 저장 + 호출"

예시:

CREATE PROCEDURE add_user(
    IN p_name VARCHAR(50),
    IN p_email VARCHAR(100)
)
BEGIN
    INSERT INTO users (name, email)
    VALUES (p_name, p_email);
END;

-- 호출
CALL add_user('Alice', 'alice@example.com');

---

VIEW vs PROCEDURE ⭐ :

	VIEW	PROCEDURE
용도	정적 조회	동적 처리
반환	테이블 형태	결과 또는 영향만
매개변수	X	✅
INSERT/UPDATE	제한적	자유롭게
호출	SELECT FROM view	CALL procedure

---

프로시저의 활용:

1. 복잡한 비즈니스 로직 — DB 안에서 처리
2. 배치 작업 — 여러 SQL 묶음
3. 트랜잭션 단위 작업 — DB 차원에서 관리
4. 권한 캡슐화 — 사용자에게 직접 SQL 권한 X, 프로시저만

---

현대적 관점에서의 평가 ⚠️ :

과거 (1990~2000년대):

• DB가 강력한 곳, 애플리케이션은 약함
• 비즈니스 로직을 DB에 두는 것이 자연스러움
• 프로시저 활발히 사용

현재:

• 애플리케이션 레이어가 풍부 (Java, Spring)
• 비즈니스 로직은 애플리케이션에 두는 것이 일반적
• → 프로시저 사용 감소

프로시저의 단점:
1. 테스트 어려움 — DB에 의존
2. 버전 관리 어려움 — Git 등으로 관리 X
3. 포팅 어려움 — DBMS마다 문법 다름
4. 디버깅 어려움
5. CI/CD 어려움

실무 권장:

"비즈니스 로직은 애플리케이션에, DB는 데이터 저장에 집중"

다만 다음은 프로시저 적합:

• 대량 ETL 작업
• 보고서용 복잡 집계
• DB 어드민 작업

---

Trigger vs VIEW vs PROCEDURE 정리 ⭐ :

	Trigger	VIEW	PROCEDURE
호출	자동 (이벤트)	SELECT	CALL (수동)
매개변수	OLD/NEW	X	✅
용도	자동 부수 작업	가상 테이블	명시적 작업 단위

ILIC 권장:

• 비즈니스 로직 → Spring 서비스 레이어
• 단순 쿼리 단순화 → VIEW 가능
• 자동 감사 로그 → Trigger 또는 AOP (8-9주차)
• 복잡한 ETL → PROCEDURE 또는 Spring Batch

자기 점검

• ILIC가 비즈니스 로직을 프로시저로 안 두는 이유는? (힌트: 테스트, 버전 관리)
• 프로시저를 정말 써야 할 경우는? (힌트: DB 관리, 대량 ETL)

---

🎓 종합 자기 점검 (14주차 졸업 시험)

데이터 타입과 인코딩

1. CHAR와 VARCHAR의 차이를 한 문장으로?
2. CHAR(255)에 'A' 저장 시 디스크 사용량은?
3. BLOB과 TEXT의 가장 큰 차이는?
4. utf8_general_ci에서 'ci'의 의미는?
5. MySQL에서 대소문자 구분 검색을 강제하려면?

DB Clustering

6. Clustering의 정의와 단일 서버 대비 이점은?
7. Active-Active와 Active-Standby의 차이는?
8. 클러스터에 최소 3개 노드를 권장하는 이유는?
9. Split Brain의 정의와 위험성은?

Replication과 PXC

10. Master-Slave Replication의 구조와 이점은?
11. Replication과 Clustering의 결정적 차이 3가지는?
12. PXC가 일반 Replication보다 좋은 시나리오는?
13. XtraBackup이 mysqldump보다 적합한 경우는?

데이터 분할

14. Sharding과 Partitioning의 차이는?
15. Hash-based Sharding의 장단점은?
16. Range Partitioning이 적합한 데이터 사례는?
17. "Partitioning 우선, Sharding은 마지막"의 의미는?

삭제 명령과 ROLLBACK

18. DELETE/TRUNCATE/DROP 차이를 표로 정리하라
19. TRUNCATE가 ROLLBACK 안 되는 이유는?
20. UNDO LOG와 REDO LOG의 차이는?
21. AUTO_INCREMENT 값이 DELETE/TRUNCATE 후 어떻게 되는가?

SQL 고급 기능

22. Trigger의 활용 사례 3가지는?
23. Trigger의 단점 4가지와 대안(AOP)의 비교는?
24. INNER JOIN과 LEFT OUTER JOIN의 결과 차이를 시나리오로 설명하라
25. "주문 안 한 사용자 찾기" SQL을 작성하라
26. VIEW의 활용 사례 4가지는?
27. VIEW와 PROCEDURE의 결정적 차이는?
28. 현대 실무에서 PROCEDURE 사용이 줄어든 이유 3가지는?

---

📌 학습 운영 팁

9-섹션 마스터 프롬프트로 깊이 파야 할 Unit

★★★ 면접·실무 단골 (반드시):

• Unit 2.3 — Quorum과 클러스터 노드 수
• Unit 3.2 — Replication vs Cluster
• Unit 5.1 — DELETE vs TRUNCATE vs DROP
• Unit 6.2 — INNER vs OUTER JOIN

★★ 매우 권장:

• Unit 4.1~4.2 — Sharding과 Partitioning 차이
• Unit 5.2 — UNDO LOG와 ROLLBACK
• Unit 6.3 — VIEW의 활용
• Unit 6.4 — PROCEDURE의 현재 위치

Phase별 진도 체크리스트

[ ] Phase 1 — 데이터 타입과 인코딩 (Unit 1.1~1.3)
[ ] Phase 2 — DB Clustering (Unit 2.1~2.3)
[ ] Phase 3 — Replication과 백업 (Unit 3.1~3.3)
[ ] Phase 4 — Sharding과 Partitioning (Unit 4.1~4.2)
[ ] Phase 5 — DELETE/TRUNCATE/DROP과 ROLLBACK (Unit 5.1~5.2)
[ ] Phase 6 — SQL 고급 기능 (Unit 6.1~6.4)
[ ] 종합 자기 점검 28문항 통과

13주차 + 14주차 = DB 영역 완결

13주차 (이론):

• 정규화 → NoSQL → CAP/PACELC → 옵티마이저 → 인덱스

14주차 (운영):

• 데이터 타입 → Clustering → Replication → Sharding/Partitioning → SQL 도구

→ 이제 DB 면접에서 마주칠 대부분의 질문에 답할 수 있다.

학습 시 주의

이번 주차는 운영 실무 색채가 강합니다. 직접 손을 더럽혀야 체화됩니다:

1. Phase 2-3 (Clustering/Replication):

   • Docker Compose로 MySQL Replication 환경 구축
   • 한 컨테이너 다운 → 동작 확인
   • PXC도 Docker로 시도 (시간 여유 있다면)

2. Phase 4 (Partitioning):

   • 직접 RANGE PARTITION 테이블 생성
   • EXPLAIN으로 Partition Pruning 확인

3. Phase 5 (DELETE/TRUNCATE/DROP):

   • 트랜잭션 안에서 각 명령 실행 후 ROLLBACK 시도
   • AUTO_INCREMENT 동작 확인

4. Phase 6 (Trigger/VIEW/PROCEDURE):

   • 직접 만들어보고, ILIC 어떤 영역에 적용 가능한지 검토

특히 ILIC와 연결해서 생각하세요:

• 102 테이블 중 파티셔닝 후보는?
• Read Replica를 도입한다면 어떤 트래픽이 분산될까?
• 변경 이력 시스템을 Trigger로 했더라면 어땠을까? (AOP와의 비교)

---