[쿼리 튜닝] 2-1. 인덱스란? / 클러스터드 인덱스 (Clustered Index), 논 클러스터드 인덱스 (Non Clustered Index)

▶ 인덱스란?

---

데이터베이스에서 데이터를 더 빠르게 찾기 위해서 사용하는 자료구조이다.

책의 목차라고 생각하면 된다.

인덱스가 없으면 전체 테이블을 조회하는 풀스캔을 한다. -> 비효율적

 

 

 

 

 

▶ 인덱스의 핵심 원리

---

1️⃣ 인덱스를 생성하면, 특정 컬럼을 기반으로 정렬된 별도의 자료구조(B-Tree 등)가 만들어짐

2️⃣ 쿼리를 실행할 때, MySQL은 테이블 전체를 검색하는 대신 인덱스를 먼저 검색

3️⃣ 인덱스에서 원하는 데이터를 찾고, 해당 데이터를 빠르게 조회

 

 

 

▷ 장점

---

• 테이블을 검색하는 속도와 성능 향상 → 시스템 전반적인 부하 감소
• 데이터들이 정렬된 형태를 가짐 → 조건에 맞는 데이터를 빠르게 찾는다

 

 

▷ 단점

---

• 인덱스를 저장하기 위한 추가 저장 공간 필요
• 인덱스를 관리하기 위한 추가 작업 필요(원본 테이블에 데이터 수정, 삽입, 삭제 시에 인덱스도 같이 업데이트 해줘야함) → 검색은 빠르지만 CUD는 느려짐
• 인덱스를 너무 많이 만들면 오히려 성능 저하 → 인덱스를 통해 테이블의 레코드를 읽는 것이 더 높은 비용이 든다. → 필요한 인덱스만 만들어서 사용하기

 

 

 

▷ 인덱스를 사용하면 좋은 경우

---

• WHERE 절로 특정값을 자주 조회할 때
• JOIN을 많이 사용하는 경우
• ORDER BY, GROUP BY를 자주 사용할 때
• 큰 테이블에서 빠르게 데이터를 찾고 싶을 때

 

 

 

 

 

 

▶ 클러스터링 인덱스(Clustered Index)란?

---

✅ 데이터 자체가 인덱스에 정렬된 상태로 저장되는 인덱스

✅ 테이블의 기본 정렬 순서를 결정하는 인덱스

✅ 한 테이블에 하나만 존재할 수 있음(데이터 자체가 정렬되므로!)

 

 

 

▷ 클러스터링 인덱스의 특징

---

✔ 데이터 자체가 인덱스의 leaf node에 저장됨

✔ 프라이머리 키(PK)에 자동으로 생성됨 (InnoDB 기준)

✔ 데이터를 검색할 때 매우 빠름 (한 번 정렬되면 연속된 데이터 접근이 쉬움)

✔ INSERT/UPDATE/DELETE 시 성능 영향이 있을 수 있음 (정렬 유지해야 해서)

 

데이터 검색 순서 : 루트 페이지 → 리프 페이지(데이터 페이지)

 

 

 

▷ 어떤 경우에 생성해야할까?

---

• 테이블 데이터가 자주 업데이트 되지 않는 경우
• MAX, MIN, COUNT 등의 쿼리로 범위 또는 Group By 등의 조회를 하는 경우
• 항상 정렬 된 방식으로 데이터를 반환해야 하는 경우
• 읽기 작업이 월등히 많은 경우

 

 

 

▷ 단점

---

• 리프 페이지가 모두 차있는데 새로운 데이터가 추가된다? → 페이지 분할이 일어남.
  • 인덱스는 B-Tree 구조이기 때문에 기본적으로 모두 같은 크기의 페이지를 유지함
  • 그래서 새로운 데이터가 추가되면 기존 데이터 절반이 새로운 페이지로 이동한 후에 새로운 행이 추가됨.
  • 이와 같이, 인덱스를 생성/수정/삭제할 때 페이지 분할이 일어남
    • → 데이터 페이지 전체를 다시 정렬해야 하기 때문에 느림

 

 

 

 

 

 

▶ 논클러스터링 인덱스(Non-Clustered Index)란?

---

 

✅ 데이터 페이지는 건드리지 않고, 별도의 인덱스 구조를 만들어 관리하는 인덱스

✅ 클러스터링 인덱스와 달리 여러 개 만들 수 있음

✅ 인덱스가 가리키는 값(ROW ID)을 이용해 원본 테이블에서 실제 데이터를 찾아야 함

 

 

 

▷ 논클러스터링 인덱스의 특징

---

✔ 실제 데이터는 정렬되지 않음. 인덱스만 정렬됨.

✔ 보조 인덱스(Secondary Index)라고도 부름

✔ 인덱스를 생성할 때 데이터 페이지는 그냥 둔 상태에서 별도의 인덱스 페이지를 따로 만들기 때문에 용량을 더 차지

✔ 클러스터형보다 검색 속도는 더 느리지만 데이터의 입력, 수정, 삭제는 더 빠르다.→ 클러스터드 인덱스보다 페이지 분할이 적게 일어남.

✔ 검색 시 인덱스를 찾고, 다시 테이블을 조회해야 해서 추가적인 I/O 발생

✔ 한 테이블에 여러 개 만들 수 있음

 

데이터 검색 순서 : 루트페이지 > 리프페이지 > 데이터 페이지 (Heap page)

 

 

 

▷ 어떤 경우에 생성해야할까?

---

• WHERE 절이나 JOIN 절과 같이 조건문을 활용하여 테이블을 필터링 하고자 할 경우
• 데이터가 자주 업데이트 될 경우
• 특정 컬럼이 쿼리에서 자주 사용 될 경우

 

 

 

▷ 단점

---

• 인덱스 페이지만을 위한 추가 저장공간이 필요하다.
• 데이터 접근 속도가 클러스터 인덱스보다 상대적으로 느리다.
• 인덱스 조회 시 비용이 많이 발생한다.
  • 검색하고자 하는 데이터의 키 값을 루트 페이지에서 비교하여 리프 페이지 번호 찾기
  • 리프 페이지에서 RID 정보로 실제 데이터의 위치로 이동

 

 

 

 

 

---

▶ 다음 글 읽으러 가기!

---

https://learning-study.tistory.com/entry/%EC%BF%BC%EB%A6%AC-%ED%8A%9C%EB%8B%9D-2-2-%EC%BF%BC%EB%A6%AC-%EC%9D%B8%EB%8D%B1%EC%8A%A4-%ED%8A%9C%EB%8B%9D-%EB%8B%A8%EC%9D%BC-%EC%9D%B8%EB%8D%B1%EC%8A%A4-%EB%B3%B5%ED%95%A9%EC%9D%B8%EB%8D%B1%EC%8A%A4

[쿼리 튜닝] 2-2. 쿼리 인덱스 튜닝 / 단일 인덱스, 복합인덱스