Phase 2레슨 6
Database
RDB, SQL, Index, Transaction, ACID — 데이터를 어떻게 저장하고 조회하는가
💡ELI5·
DB를 도서관에 비유하면
SQL 문장 → Parser → Optimizer → Executor → 결과 행
💡 비유 — SQL = 도서관 사서에게 요청하는 방식. '2020년 이후 출간된 컴퓨터 책 제목과 저자를 알려줘'라고 하면, 사서가 직접 서가를 뒤지고 색인 카드를 확인한다. 질의자는 어디에서·어떤 순서로 찾을지 지시하지 않는다 — 이것이 Optimizer의 역할.
🔬Deep Dive·
Index — B-Tree의 동작
Index가 없으면 DB는 모든 행을 처음부터 끝까지 확인해야 한다(Full Table Scan, O(N)). Index가 있으면 B-Tree를 타서 O(log N)으로 데이터를 찾는다. 1억 행에서 Full Scan은 최대 1억 번, B-Tree는 약 27번의 비교로 데이터를 찾는다.
| 인덱스 유형 | 구조 | 적합한 조회 |
|---|---|---|
| B-Tree | 균형 트리, 범위 조회 가능 | =, <, >, BETWEEN, LIKE 'prefix%' |
| Hash | 해시 테이블, 등조인만 | = (정확 매치) |
| Composite | 다중 컬럼 B-Tree | 다중 조건 조회 (순서 중요) |
| Covering | 모든 필요 컬럼이 인덱스에 포함 | 테이블 접근 없이 인덱스만으로 조회 |
-- 인덱스 생성
CREATE INDEX idx_users_email ON users(email);
-- 실행 계획 확인
EXPLAIN ANALYZE
SELECT * FROM users WHERE email = 'user@example.com';
-- Composite Index (선택도 높은 컬럼 순서)
CREATE INDEX idx_orders_user_status
ON orders(user_id, status);🔬Deep Dive·
Transaction / ACID
은행 송금 예시: A에서 100을 차감하고 B에 100을 추가하는 두 연산이 하나의 트랜잭션으로 묶여야 한다. 중간에 장애가 나면 전체가 롤백되어야 한다(Atomicity).
| 항목 | 의미 | 보장 방법 |
|---|---|---|
| Atomicity | 전부 성공 또는 전부 실패 | Undo Log / Rollback |
| Consistency | 데이터 무결성 유지 | 제약조건 (PK, FK, CHECK) |
| Isolation | 동시 트랜잭션 간섭 방지 | Lock / MVCC |
| Durability | 커밋된 데이터 영구 저장 | Redo Log / WAL |
| Isolation Level | Dirty Read | Non-Repeatable | Phantom Read |
|---|---|---|---|
| Read Uncommitted | 가능 | 가능 | 가능 |
| Read Committed | 방지 | 가능 | 가능 |
| Repeatable Read | 방지 | 방지 | 가능 (MySQL은 방지) |
| Serializable | 방지 | 방지 | 방지 |
⚖️Trade-off·
Index의 Trade-off
Index는 읽기 성능을 크게 향상시키지만, 쓰기(INSERT, UPDATE, DELETE) 시 인덱스도 갱신해야 하므로 쓰기 성능이 저하된다. 또한 디스크 공간을 추가로 사용한다. 모든 컬럼에 인덱스를 만드는 것은 안 된다.
❓ 체크포인트 질문
- 1.B-Tree 인덱스가 Full Table Scan보다 빠른 이유는?
- 2.ACID의 각 항목이 보장하는 것은?
- 3.Composite Index에서 컬럼 순서가 왜 중요한가?
- 4.Isolation Level이 낮을 때 발생할 수 있는 문제는?
- 5.은행 송금에서 Atomicity가 없다면 어떤 문제가 발생하는가?