📌 빠른 데이터 검색을 위한 인덱스

인덱스는 데이터베이스 테이블에서 데이터 검색을 빠르게 하기 위한 자료구조입니다.

마치 책의 색인처럼, 원하는 데이터를 빠르게 찾아주는 역할!

그러나 인덱스가 많아지면 INSERT, UPDATE, DELETE 시 오버헤드가 발생 → 관리 주의 필요! 🚨

---

📚 인덱스의 개념과 종류

인덱스 종류	설명	특징
PRIMARY 인덱스	기본 키(Primary Key)에 자동 생성되는 인덱스	NULL 허용 X, 테이블 내 유일 식별자, 클러스터드 인덱스로 동작 (MySQL InnoDB 기준)
UNIQUE 인덱스	중복 없는 고유값을 강제 → 중복 데이터 허용 X	여러 개 생성 가능, NULL 허용 가능 (단, NULL 중복은 허용)
FULLTEXT 인덱스	대용량 텍스트 필드에서 단어, 문장 검색 최적화	CHAR, VARCHAR, TEXT 컬럼에서 사용, 자연어 검색 지원
SPATIAL 인덱스	공간 데이터 (위치, 지리정보 등) 검색 최적화	GIS 데이터(GEOMETRY, POINT, POLYGON) 등 공간 연산에서 빠른 검색 가능

---

🔍 클러스터드 & 넌클러스터드 인덱스

구분	클러스터드 인덱스 (Clustered)	넌클러스터드 인덱스 (Non-Clustered)
정의	데이터가 인덱스 순서에 맞게 실제 저장	인덱스와 데이터가 별도 저장, 포인터로 연결
테이블당 생성 수	1개만 가능 (기본 키와 동일)	여러 개 가능
장점	데이터 정렬 & 조회 빠름, 범위 검색 효율적	다양한 컬럼에 인덱스 생성 가능, 데이터 수정 시 유연
단점	데이터 추가/삭제 시 물리적 재정렬 필요 → 부하	데이터 조회 시 추가로 데이터 위치 탐색 필요 → 느릴 수 있음
MariaDB에서 적용 예시	PRIMARY KEY = 클러스터드 인덱스 (InnoDB 엔진 기준)	UNIQUE, 일반 인덱스 등 대부분 넌클러스터드 인덱스

---

🛠️ 각 인덱스 유형별 사용 예시

1️⃣ PRIMARY 인덱스

CREATE TABLE student (
  id INT PRIMARY KEY,
  name VARCHAR(50)
);

기본 키로 자동 인덱스 생성, 고유 식별자 보장!

---

2️⃣ UNIQUE 인덱스

CREATE UNIQUE INDEX idx_email ON student(email);

중복 없는 이메일 보장, NULL은 여러 번 허용

---

3️⃣ FULLTEXT 인덱스

CREATE FULLTEXT INDEX idx_content ON articles(content);

대량 텍스트(content 컬럼)에서 빠른 단어 검색 가능

---

4️⃣ SPATIAL 인덱스

CREATE SPATIAL INDEX idx_location ON places(location);

위치 기반 데이터 검색 최적화, GIS 쿼리에서 성능 UP!

---

⚠️ 인덱스 주의사항

고려사항	설명
과도한 인덱스 생성 X	인덱스가 많으면 INSERT, UPDATE, DELETE 성능 저하
불필요한 넓은 인덱스 자제	자주 검색, 정렬, 조건절에 사용되는 컬럼 위주로 인덱스 생성
카디널리티(Cardinality) 고려	컬럼의 고유값 비율이 높을수록 인덱스 효율적 (예: 주민번호, ID 등)
인덱스 크기 관리	인덱스도 디스크 공간 차지 → 불필요한 인덱스는 주기적으로 점검 & 삭제

---

📌 정리

📌 인덱스란? → 검색 성능 향상 위한 데이터 구조, 책의 색인처럼 빠른 탐색 가능
📌 종류 → PRIMARY, UNIQUE, FULLTEXT, SPATIAL
📌 클러스터드 vs 넌클러스터드 → 저장 방식 차이, 성능 영향
📌 주의 → 과도한 인덱스 사용 지양, DML 작업 시 오버헤드 고려

---

📌 인덱스란? - 책의 목차(색인)와 같다!

• 비유: 📖 두꺼운 책에서 원하는 내용을 찾을 때, 매번 책 전체를 처음부터 끝까지 훑는 것보다 목차나 색인을 보면 바로 찾을 수 있죠?

→ 데이터베이스도 마찬가지!

테이블 전체를 처음부터 검색하지 않고 인덱스라는 목차를 통해 빠르게 필요한 데이터를 찾아냅니다.

---

🟢 인덱스의 효과

효과	비유	설명
1. 데이터 검색 속도 향상	책의 색인	책의 색인으로 페이지를 바로 찾듯, WHERE 조건의 열에 인덱스를 걸면 빠르게 데이터 찾기 가능
2. 정렬된 결과 반환	사전	사전처럼 이미 정렬된 상태 → ORDER BY 시 정렬 작업 부담이 적음
3. 범위 검색 최적화	전화번호부	이름 A~D까지만 찾을 때, 전화번호부처럼 범위 검색이 빠름 (예: WHERE age BETWEEN 20 AND 30)

---

🛠️ 성능 최적화 기법

최적화 방법	비유	설명
1️⃣ 적절한 인덱스 설계	가게에서 자주 팔리는 상품 진열대에 배치	자주 쓰이는 컬럼(검색, JOIN, 정렬 컬럼)에 인덱스를 걸어야 효과적! 불필요한 인덱스 = 공간 낭비
2️⃣ 인덱스 통계 유지	도서관 책 배치도 최신화	데이터가 많아지면 인덱스 통계 정보도 업데이트! → DB가 더 좋은 실행 계획 세움
3️⃣ 인덱스 갱신 비용 고려	책마다 색인 붙이기 = 관리 비용	INSERT, UPDATE, DELETE 시 인덱스도 같이 수정 → 너무 많으면 오히려 느려짐. 꼭 필요한 것만!
4️⃣ 쿼리 최적화 (리팩토링)	가게에서 손님 동선 짧게 정리	불필요한 JOIN, WHERE 조건 제거 & 인덱스 잘 타도록 쿼리 작성! → 실행 계획(EXPLAIN)으로 확인 가능

---

🔥 비유로 쉽게 핵심 정리

개념	비유	요점
인덱스	책의 색인, 도서관의 책 배치도	빠르게 원하는 데이터 위치 찾기
너무 많은 인덱스	모든 페이지에 포스트잇 붙여놓기	오히려 관리 부담, 성능 저하
적절한 인덱스 설계	가게에서 인기 상품 앞에 배치	자주 쓰는 열에만 인덱스 걸기
갱신 비용	책 내용 바꿀 때마다 색인 다시 만들기	DML 작업 많으면 인덱스 부담 커짐
쿼리 최적화	동선 줄이기, 메뉴 정리	쿼리 안에서 인덱스 잘 활용하도록 작성

---

🔍 실무 적용 꿀팁 (비유 포함)

꿀팁	비유	설명
1️⃣ WHERE, JOIN, ORDER BY에 자주 쓰는 컬럼 = 인덱스 후보	🏪 마트에서 사람들이 자주 찾는 물건은 입구 근처에 배치!	사람들이 자주 찾는 상품(자주 검색하는 컬럼)은 입구(인덱스) 가까이에 두어야 찾기 빠름! → WHERE, JOIN, ORDER BY에 자주 등장하는 컬럼은 꼭 인덱스!
2️⃣ EXPLAIN으로 인덱스 사용 여부, Full Scan 여부 꼭 확인	🔍 지도 앱에서 경로 미리 확인하는 것!	목적지(쿼리 결과) 가기 전에 빠른 길(인덱스 타는지) 확인하는 것! EXPLAIN으로 실행 계획 보면, 전체 테이블 다 훑는 Full Scan인지 확인 가능! 불필요한 Full Scan → 🚫
3️⃣ DML 빈번한 테이블은 인덱스 최소화 (변경 비용↑)	📦 자주 정리하는 창고에 포스트잇 너무 많이 붙이면 정리하기 불편!	INSERT, UPDATE, DELETE 자주 하는 테이블은 인덱스 많으면 매번 인덱스도 같이 갱신해야 함 → 느려짐! 꼭 필요한 인덱스만 최소화
4️⃣ 다중 컬럼 인덱스는 컬럼 순서 중요 (가장 자주 조건 거는 열 먼저!)	🏙️ 도로 표지판: 고속도로에서 먼저 나오는 방향 표시!	예를 들어 (A, B) 순서로 만든 인덱스면, A 기준으로 검색해야 인덱스 제대로 사용됨. B 먼저 쓰면 인덱스 무용지물! → 가장 많이 조건 거는 컬럼을 앞에 배치!

---

🎯 한 줄 핵심 정리

꿀팁 번호	핵심
1️⃣	자주 검색, 정렬, JOIN에 쓰이는 컬럼 → 반드시 인덱스 후보
2️⃣	EXPLAIN으로 항상 실행 계획 확인 → Full Scan 나오면 개선 필요!
3️⃣	INSERT, UPDATE 많은 테이블은 인덱스 최소화 → DML 부담 줄이기
4️⃣	다중 컬럼 인덱스 → 가장 자주 필터 거는 컬럼부터 먼저!

---

📄 결론

• 인덱스 = 책의 색인, 빠른 검색 도구
• 잘 설계하면 검색은 빠르고 효율적!
• 그러나 너무 많거나 잘못 관리하면 오히려 성능 저하
• 쿼리 리팩토링, 통계 관리, 인덱스 재설계 → 꾸준히 관리해야 고성능 유지! 🚀

---

🔍 실행 계획 분석

📊 실행 계획이란?

실행 계획은 데이터베이스가 쿼리를 실행하기 위해 선택한 경로를 설명하는 것으로, 쿼리의 성능을 분석하고 최적화하는 데 사용됩니다. MySQL에서는 EXPLAIN 명령어를 사용하여 실행 계획을 확인할 수 있습니다.

🛠️ EXPLAIN 명령어 사용법

EXPLAIN SELECT * FROM employees WHERE department_id = 10;

위 명령어를 실행하면, 데이터베이스가 해당 쿼리를 어떻게 처리하는지에 대한 정보를 제공합니다. 이 정보를 통해 쿼리의 성능 병목 지점을 파악하고 최적화할 수 있습니다.

---

🔄 쿼리 최적화 기법

🛠️ 쿼리 리팩토링을 통한 속도 향상

1. 서브쿼리 최적화
   • 서브쿼리는 종종 성능 저하의 원인이 될 수 있습니다. 이를 공통 테이블 표현식(CTE)이나 조인으로 변환하여 성능을 향상시킬 수 있습니다.

   예시: 서브쿼리를 CTE로 변환

    WITH MaxSalary AS (
        SELECT MAX(salary) AS max_salary
        FROM salaries
        WHERE from_date > '2000-01-01'
    )
    SELECT e.emp_no, e.first_name, e.last_name, s.salary
    FROM employees e
    JOIN salaries s ON e.emp_no = s.emp_no
    JOIN MaxSalary ms ON s.salary = ms.max_salary
    WHERE e.hire_date < '1995-01-01'
    ORDER BY e.hire_date DESC;
   

   위 예시에서 서브쿼리를 CTE로 변환하여 성능을 향상시켰습니다.

2. 인덱스 활용
   • 적절한 인덱스를 생성하여 데이터 검색 속도를 향상시킬 수 있습니다. 그러나 과도한 인덱스는 오히려 성능을 저하시킬 수 있으므로, 필요한 인덱스만 생성하는 것이 중요합니다.

   예시: 인덱스 생성

    CREATE INDEX idx_salaries_salary ON salaries(salary);
    CREATE INDEX idx_salaries_from_date ON salaries(from_date);
    CREATE INDEX idx_employees_hire_date ON employees(hire_date);
   

   위 예시에서는 쿼리에서 자주 사용되는 열에 인덱스를 생성하여 성능을 향상시켰습니다.

3. 불필요한 컬럼 제거: 사용하지 않는 컬럼의 조회를 피하여 I/O 부담을 줄입니다.
4. 조인 순서 최적화: 조인의 순서를 변경하여 작은 테이블부터 먼저 조인하도록 하여 성능을 향상시킬 수 있습니다.

🔄 쿼리 최적화 기법 쉽게 이해하기!

기법	비유	설명
1️⃣ 서브쿼리 최적화 → CTE로 변환	🏭 공장에서 매번 재료를 따로따로 주문하는 것보다 한 번에 재고 정리해두고 쓰는 것!	서브쿼리를 계속 실행하면 매번 새로 검색하느라 시간 낭비. → CTE(Common Table Expression)로 한 번 정리해두고 여러 번 재활용하면 빠름!
2️⃣ 인덱스 활용	📚 책에 색인(Index)이 있으면, 원하는 내용 바로 찾을 수 있음!	WHERE, JOIN, ORDER BY에서 자주 쓰는 컬럼에 인덱스를 걸어주면 검색이 훨씬 빠름. 단, 너무 많은 색인(인덱스)은 오히려 책이 두꺼워지고 관리가 힘들어짐 (DML 시 비용 ↑)
3️⃣ 불필요한 컬럼 제거	🍱 도시락 배달할 때 안 먹을 반찬까지 다 싸오면 무거워지고 느려짐!	쿼리에서 필요한 컬럼만 SELECT! → SELECT * 사용 금지! → 불필요한 데이터까지 들고 오는 I/O 부담 줄임
4️⃣ 조인 순서 최적화	🛒 마트에서 장 볼 때 무거운 쌀부터 먼저 사고 돌아다니면 힘듦 → 가벼운 것부터 먼저 담기!	큰 테이블 먼저 조인하면 메모리 부담 커짐 → 작은 테이블부터 먼저 조인하도록 쿼리 작성!

---

🎯 핵심 정리

최적화 기법	한 줄 요약
서브쿼리 → CTE로 변환	공통 데이터를 먼저 계산 & 저장, 중복 연산 줄이기
인덱스 활용	책의 색인처럼 빠른 검색용, 필요한 열만!
불필요한 컬럼 제거	필요한 정보만 들고오기! SELECT * 금지!
조인 순서 최적화	작은 테이블부터 먼저 조인해서 메모리 부담 줄이기

⚙️ 캐시 및 성능 튜닝 기법

1. 쿼리 캐시 활용
   • 반복적으로 실행되는 동일한 쿼리에 대해 결과를 캐시하여 성능을 향상시킬 수 있습니다. 그러나 MySQL 8.0부터는 쿼리 캐시 기능이 제거되었으므로, 애플리케이션 레벨에서 캐싱을 구현해야 합니다.
2. 옵티마이저 힌트 사용
   • 쿼리 실행 시 옵티마이저에게 특정 실행 계획을 사용하도록 지시하는 힌트를 제공하여 성능을 최적화할 수 있습니다.

   예시: 인덱스 힌트 사용

    SELECT * FROM test USE INDEX (idx_name)
    WHERE name IN ('1', '2', ..., '150') AND second_name IN ('1', '2', ..., '150');
       
   

   위 예시에서는 USE INDEX 힌트를 사용하여 특정 인덱스를 활용하도록 지시하였습니다.

3. 데이터베이스 파라미터 튜닝
   • 서버의 메모리, 스토리지 성능, 네트워크 대역폭 등을 고려하여 데이터베이스의 설정 값을 조정함으로써 성능을 향상시킬 수 있습니다. -

🚀 캐시 및 성능 튜닝 기법 쉽게 이해하기!

기법	비유	설명
1️⃣ 쿼리 캐시 활용	🍽️ 자주 주문하는 메뉴는 미리 만들어 놓고 바로 내주는 패스트푸드점!	같은 쿼리를 계속 요청하면, 매번 새로 요리하지 않고 미리 결과 저장(캐시)해 두었다가 바로 제공 → 속도 향상!※ MySQL 8.0 이상에서는 서버 레벨 캐시는 사라져서, 애플리케이션에서 Redis 같은 캐시 써야 함!
2️⃣ 옵티마이저 힌트 사용	🚦 내비게이션에게 “이 길로 가!”라고 알려주는 것!	DB가 쿼리 실행 계획을 스스로 짜지만, 가끔 돌아가는 길을 선택할 수도 있음. → 힌트(예: USE INDEX)로 빠른 길을 강제로 알려주기!
3️⃣ DB 파라미터 튜닝	🛠️ 자동차 엔진, 타이어 공기압, 연료 효율 조정하는 것!	서버 메모리, 버퍼 크기, 스레드 수 등은 자동차 세팅과 같음. → 메모리 너무 적으면 느림, 너무 많으면 낭비 → 서버 환경에 맞게 맞춤 설정 필요!

---

🎯 핵심 정리

성능 튜닝 기법	쉽게 이해하는 한 줄
쿼리 캐시	자주 요청되는 메뉴는 미리 만들어 둠 (속도 ↑)
옵티마이저 힌트	내비게이션에게 “이쪽 길로 가!” 알려주는 것
DB 파라미터 튜닝	자동차 엔진 세팅 맞추듯, 서버 환경에 최적화

---