✅ DB 인덱싱(Database Indexing) 이란?

✅ DB 인덱싱 (Database Indexing)

🔹 “데이터베이스의 목차(Book Index)” 역할을 하는 구조

예를 들어,
cafes 테이블에 카페가 10,000개 있다면
WHERE name = '놀숲 강남점' 같은 쿼리를 날릴 때
인덱스가 없으면 → 맨 앞에서부터 하나씩 다 찾습니다 (Full Table Scan)
인덱스가 있으면 → 목차에서 바로 해당 위치로 점프합니다 (Logarithmic Search)

---

📘 MySQL에서 인덱스 설정 방법 (명령 한 줄)

CREATE INDEX idx_cafe_name ON cafes(name);

➡ 이름 컬럼 기준으로 인덱스 생성
➡ 이 한 줄이면, WHERE name = ?, WHERE name IN (...) 쿼리가 즉시 빨라집니다.
➡ 추가 비용: 데이터 INSERT/UPDATE 시 인덱스도 같이 갱신돼서 약간의 오버헤드 생기지만 검색은 수십 배 빨라집니다.

즉:
인덱스는 “검색을 빠르게 하는 자동 자료구조 (B-Tree)” 라고 생각하시면 돼요.

---

MySQL이 인덱스를 만들면 진짜로 “처음부터 끝까지 훑어서(A~Z 순)” 내부적으로 ‘목차(B-Tree)’ 구조를 생성해둡니다.
즉 사람이 책에서 “이 단어는 P로 시작하니까 P 섹션으로 가야지” 하는 것처럼,
MySQL도 데이터를 정렬된 구조로 재배치해서 탐색 속도를 극적으로 줄입니다.

---

🧠 좀 더 구체적으로

① 처음에는 “풀 스캔(Full Table Scan)”

인덱스가 없을 때는 이런 식이에요:

for each row in cafes:
	if name == '놀숲 강남점':
    	return row

➡ 데이터가 10만 개면 10만 번 비교합니다.
➡ 결과: 느림.

---

② 인덱스를 만들면 “B-Tree” 생성

CREATE INDEX idx_cafe_name ON cafes(name);

하면 MySQL은 정렬된 B-Tree 구조를 별도로 만듭니다.

• 루트 노드: A~Z 구간 구분
• 중간 노드: 더 세부적인 범위
• 리프 노드: 실제 데이터의 위치 포인터(row pointer)

        [M]
       /   \
  [A~L]   [N~Z]
   ↓         ↓
 "놀숲" → row#15023

➡ 이제는 “놀숲 강남점”을 찾을 때
트리 높이만큼만 (보통 3~4단계) 내려가면 바로 찾습니다.
➡ 즉, 10만 개 → 약 20~30회 비교로 끝나요.

---

③ 내부적으로 정렬되어 유지됨

• 인덱스는 항상 정렬 상태 유지
• 새로운 데이터가 들어올 때마다
  B-Tree에 자동 삽입 (정렬된 위치에)
  → 그래서 INSERT/UPDATE가 약간 느려지는 이유가 이것이에요.
  (목차도 같이 업데이트해야 하니까)

---

④ 인덱스가 유용한 쿼리 유형

쿼리 형태인덱스 사용이유

WHERE name = '놀숲 강남점'	✅	정확히 매칭
WHERE name IN ('놀숲', '펠트커피')	✅	범위 탐색 가능
WHERE name LIKE '놀%'	✅	접두사 검색 가능 (정렬 덕분)
WHERE name LIKE '%남점'	❌	뒤쪽 패턴은 정렬 활용 불가

---

⑤ 요약하자면

인덱스는 “정렬된 자료구조 (B-Tree)”로,
데이터를 미리 사전순(또는 숫자순) 으로 나열해둔 “목차”라고 보면 됩니다.

그래서 이름 컬럼 기준 인덱스를 만들어두면
MySQL은 “놀숲 강남점” 찾을 때 처음부터 끝까지 안 훑고
B-Tree를 타고 바로 점프해서 결과를 가져오는 거예요.

---

✅ 인덱스는 “한 번 만들어두면 계속 유지되는 목차”

• 맞아요. 인덱스는 한 번 CREATE INDEX로 만들어두면
  MySQL이 데이터가 추가되거나 수정될 때마다 자동으로 B-Tree를 갱신합니다.
• 즉, “처음 한 번 전체 스캔해서 목차 생성 → 이후엔 유지 관리” 구조입니다.
• 그래서 처음 인덱스 생성 시만 느리고, 이후에는
  • SELECT (조회)는 트리 탐색만 하므로 ⚡ 매우 빠름
  • INSERT/UPDATE는 트리 갱신 비용이 조금 늘어남 (보통 미미)

➡ 즉, 개발 중엔 “처음 인덱스 생성 시”만 전체 스캔이 일어나고,
운영(배포) 단계에선 이미 인덱스 구조가 만들어져 있으니 바로 B-Tree 탐색으로 접근합니다.

---

✅ 그래서 실제로 일어나는 일 요약

1️⃣ 처음 인덱스 생성 → MySQL이 테이블 전체 훑어서 정렬된 B+Tree 목차 생성
2️⃣ 이후 쿼리 수행 시 →

WHERE name = '놀숲 강남점'

→ 루트 → 중간 노드 → 리프 노드 순으로 3~4단계만 내려가서 바로 찾음
(Full Scan 대비 수천 배 빠름)
3️⃣ 새로운 카페 등록 시 → 자동으로 해당 키를 B+Tree에 삽입, 재균형 유지

---

📚 한 줄 요약

✅ 인덱스는 “DB가 자동으로 관리하는 정렬된 목차(B+Tree)”
✅ 한 번 만들어두면 계속 유지되며,
✅ Binary Tree보다 자식이 여러 개인 고속 검색 트리 구조입니다.