[ DB & SQL(RDBMS, NoSQL) ] 데이터 베이스 기초 이해_06.:인덱스(Index)의 개념과 구조.

▽ 데이터 베이스 기초 이해_06 :인덱스(Index)의 개념과 구조.

5. 인덱스(Index)의 개념과 구조.

---

💬 면접 예상 질문(기본 개념 위주).

1. 인덱스(Index)란 무엇인가요?

'인덱스'는 테이블의 특정 컬럼에 대해 빠르게 데이터를 검색 가능하도록 도와주는 자료구조.
책의 목차처럼 원하는 데이터를 빠르게 찾아가는 역할을 수행.

• '인덱스'는 데이터베이스 테이블에서 "검색 기능을 높이기 위해 사용하는 자료구조"

• 주로 B-Tree 또는 Hash 구조로 구현되며, 특정 컬럼에 대해 생성.

• 책의 목차처럼, 원하는 데이터를 직접 찾지 않고 "참조 포인터"를 통해 빠르게 접근할 수 있게 도와줌.

• 인덱스를 사용하지 않으면
  DB는 전체 데이터를 "Full Table Scan" 해야 하므로, 검색 시간이 오래 걸림.

2. 인덱스가 없는 테이블에서 검색은 어떻게 동작하나요?

'인덱스'가 없다면, DB는 테이블의 모든 행을 처음부터 끝까지 비교하는 "Full Table Scan"을 수행.
특히 데이터가 많을수록 성능이 저하됩니다.

• 인덱스가 없는 상태에서는 SELECT문을 수행할 때 DB는 해당 테이블의 모든 행을 순차적으로 탐색하며,
  조건에 맞는 데이터를 찾게 됨.
  • 이를 Full Table Scan 이라고 함.
• ex)

SELECT * FROM users WHERE name = 'kim';

-> name 컬럼에 인덱스가 없다면, 모든 레코드를 직접 비교.

• 이는 데이터가 적을 때는 큰 차이가 없지만, '수십만~수천만 건 이상'되면 성능 저하가 심각.

3. 인덱스가 성능에 긍정적인 영향을 주는 이유는 무엇인가요?

'인덱스'를 사용하면 전체 테이블을 조회할 필요 없이, 필요한 데이터에 바로 접근 가능하기에,
디스크 I/O를 줄이고 검색 속도를 크게 향상시킬 수 있음.

• "인덱스"는 '검색 기능'을 향상시키는 '핵심 도구'

  • 이유.
    • ✅ 빠른 검색: 전체 테이블 탐색 없이 인덱스만으로 원하는 위치를 찾음.
    • ✅ 디스크 I/O 감소: 필요한 데이터 블록만 읽으므로 효율적.
    • ✅ 정렬 최적화: ORDER BY 절이 인덱스 정렬 순서와 일치하면 성능 향상.
    • ✅ 조인 성능 향상: 조인 대상 컬럼에 인덱스가 있으면 탐색 범위 축소.

• 단, 인덱스가 무조건 빠른 것은 아님.

  • "데이터 수정이 많은 컬럼"엔 오히려 부담이 될 수 있음.

4. B-Tree 인덱스의 구조와 특징은 무엇인가요?

B-Tree 인덱스는 균형 이진 트리 형태로, 데이터를 정렬된 형태로 관리.
탐색,삽입,삭제가 효율적이고 대부분의 RDBMS에서 기본 인덱스로 사용.

• B-Tree 인덱스는 대부분의 RDBMS에서 기본적으로 사용하는 인덱스 구조.

• 정확히는 Balanced Tree(Balanced Search Tree) 구조로, 탐색 & 삽입 & 삭제 모두
  O(log n)시간 복잡도를 가짐.

• 구조 특징.

  • 🌲 트리 구조로 계층적 저장.
  • 📚 정렬된 순서로 저장되므로 범위 조회에 유리
  • 🪄 중복 제거 및 정렬, 범위 검색 최적화
  • 📦 리프 노드에 실제 레코드 위치 정보 저장

ex)

SELECT * FROM users WHERE age BETWEEN 20 AND 30;

-> B-Tree 인덱스를 통해 효율적으로 범위 탐색이 가능.

5. Hash 인덱스는 어떤 특징을 가지나요?

Hash 인덱스는 해시 함수를 이용해서 '키 값'을 '해시 버킷'으로 매핑.
'동등 비교'에는 매우 빠르지만, '정렬'이나 '범위 검색'에는 적합하지 않음.

• Hash 인덱스는 '해시 함수'를 기반으로 인덱스를 구성하여,
  특정 값의 정확한 검색(Equal Lookup)에 매우 뛰어난 성능을 보임.

• 특징.

  • ⚡ O(1)에 가까운 탐색 성능 (동등 조건에서).
  • ❌ 정렬된 순서가 없으므로 범위 검색, ORDER BY, LIKE 등에 적합하지 않음
  • ❌ 충돌 발생 시 처리 복잡도 증가.
  • ✅ 메모리 기반 In-Memory DB 또는 특정 조건(= 비교)에서 유리.

• ex)

SELECT * FROM cache WHERE session_id = 'abc123';

-> 해시 인덱스가 효과적.

• PostgreSQL은 Hash 인덱스를 명시적으로 사용해야 하며,
• MySQL의 MEMORY 엔진은 기본적으로 Hash 인덱스를 사용.

6. B-Tree와 Hash 인덱스의 차이점은 무엇인가요?

B-Tree는 범위 조회와 정렬이 가능한 반면, Hash 인덱스는 동등 비교만 빠름.
B-Tree는 대부분의 상황에 유용하고, Hash는 = 조건에 최적화된 인덱스.

항목	B-Tree 인덱스	Hash 인덱스
검색 방식	노드 순회 (정렬 기반)	해시 함수 기반
범위 조회	가능 (BETWEEN, >, <)	불가능
정렬 지원	가능 (ORDER BY)	불가능
LIKE 연산	접두사 검색 가능	불가능
성능	대부분의 상황에서 안정적	동등 비교 = 조건에서 매우 빠름
활용 환경	범용 인덱스	메모리 기반 캐시, In-Memory DB 등
대표 사용처	RDBMS 기본 인덱스	MySQL MEMORY 엔진 등

B-Tree는 범용적, Hash는 특화된 상황에서 사용하는 것이 적절. !

7. 클러스터드 인덱스(Clustered Index)란 무엇인가요?

'클러스터드 인덱스'는 '인덱스 순서'가 실제 데이터의 저장 순서와 동일한 인덱스.
하나의 테이블에 하나만 만들 수 있고, 기본 키에 주로 사용.

• "클러스터드 인덱스(Clustered Index)"는 '리프 노드에 실제 데이터가 존재'하는 인덱스 구조.
  • 즉, 인덱스 자체가 데이터.
• 특징.
  • 데이터가 '인덱스 순서대로 정렬'되어 저장.
  • '테이블당 하나만 존재 가능' ( 데이터의 실제 저장 순서가 결정되기 때문 )
  • 일반적으로 'Primary Key'에 자동 생성됨.
  • 범위 검색, 정렬된 조회에 최적화.

-ex)

SELECT * FROM users ORDER BY created_at;

-> " created_at " 이 클러스터드 인덱스면 디스크 접근 최소화 가능.

8. 넌클러스터드 인덱스(Non-clustered Index)란 무엇인가요?

'넌클러스터드 인덱스' 는 인덱스에 데이터의 참조 주소만 저장되는 형태.
한 테이블에 여러 개 만들 수 있으며, '리프 노드'에는 실제 데이터가 없음.

• "넌클러스터드 인덱스"는 "리프 노드에 실제 데이터가 아닌,
  해당 레코드의 위치(ROW ID 등)"만 포함하는 인덱스.

• 특징.

  • 테이블에 "여러 개 생성 가능"
  • 인덱스를 통해 참조한 후, "실제 데이터에 접근(Bookmark Lookup)" 필요.
  • 클러스터드 인덱스보다 느릴 수 있음 (두 번 접근)

• ex)

SELECT name FROM users WHERE email = 'a@b.com';

-> email에 Non-Clustered 인덱스가 있으면 ROW ID로 접근 후 name 조회

• ✅ 실무에서는 자주 조회되지만 정렬/범위 조건이 없는 컬럼에 주로 사용.

9. 프라이머리 키와 인덱스의 관계는 무엇인가요?

'프라이머리 키'는 자동으로 유니크 제약과 '클러스터드 인덱스'를 함께 생성.
즉, 프라이머리 키는 '고유성'을 보장할 뿐만 아니라, '성능 향상'도 도모함.

• 'Primary Key는 논리적 제약조건'이며, 대부분의 RDbMS는 이를 선언할 때
  아래의 것들을 자동으로 생성.

  • UNIQUE 제약 조건
  • NOT NULL
  • 클러스터드 인덱스(일반적으로)

• 즉, Primary Key는 내부적으로 '인덱스로 구현'되며,

• 해당 키 값으로 데이터를 빠르게 조회 가능.

ex)

CREATE TABLE users (
  id INT PRIMARY KEY,
  name VARCHAR(100)
);

-> id 컬럼에 클러스터드 인덱스가 자동 생성. !

10. 유니크 인덱스(Unique Index)란 무엇인가요?

'유니크 인덱스'는 중복 값을 허용하지 않는 인덱스로, 데이터 무결성을 보장합니다.
이메일,주민번호 등 고유해야 하는 필드에 사용.

• '유니크 인덱스(Unique Index)'는 인덱스를 생성할 때,
  해당 컬럼의 값이 중복되지 않도록 제약을 거는 인덱스.

• 특징.

  • 중복된 데이터 삽입 시 오류 발생
  • '데이터 무결성' 보장
  • UNIQUE 제약 조건과 동일하게 작동.

• ex)

CREATE UNIQUE INDEX idx_email ON users(email);

• 활용 사례
  • 사용자 이메일, 주민등록번호, 사용자 ID 등
  • 비즈니스 로직에서 고유성이 중요한 필드.

11. 인덱스는 어떤 컬럼에 생성하는 것이 좋나요?

12. 다중 컬럼 인덱스(Composite Index)란 무엇인가요?

13. 인덱스 생성 시 주의해야 할 점은 무엇인가요?

14. 인덱스가 SELECT 성능을 향상시키는 방식은?

15. 인덱스가 INSERT/UPDATE/DELETE에 미치는 영향은?

16. 인덱스를 사용하지 않는 경우는 언제인가요?

17. NULL 값을 가진 컬럼에 인덱스를 걸 수 있나요?

18. 인덱스 스캔(Index Scan)과 테이블 스캔(Table Scan)의 차이는?

19. 인덱스 힌트(Index Hint)란 무엇인가요?

20. 인덱스를 과도하게 생성하면 어떤 문제가 생기나요?

💬 면접 예상 질문(실무적인 요소 위주).

1. 인덱스를 새로 추가해야겠다고 판단하는 기준은 무엇인가요??

2. 쿼리 성능 문제를 인덱스로 해결하는 방법은?

3. 인덱스 설계 시 조회 조건(WHERE 절)과 어떤 관계를 고려하나요?

4. Composite Index 생성 시 컬럼 순서의 기준은?

5. 인덱스가 있지만 쿼리 성능이 느린 경우의 원인과 대응은?

6. 인덱스가 걸린 컬럼을 자주 업데이트해도 괜찮은가요?

7. 인덱스가 자동으로 사용되지 않을 수 있는 경우는?

8. EXPLAIN 또는 실행 계획(Execution Plan) 분석 시 인덱스 관련 확인 포인트는?

9. 정렬(ORDER BY)과 인덱스의 관계는?

10. Group By 절에서 인덱스 활용 여부는 어떻게 판단하나요?

11. WHERE 조건에 범위 조건(BETWEEN, LIKE 등)이 있는 경우 인덱스 활용은 어떻게 되나요?

12. LIKE 검색 시 와일드카드 위치에 따른 인덱스 사용 여부는?

13. 대용량 테이블에서 인덱스를 관리한다면?

14. 인덱스 재구성(REBUILD, REORGANIZE)을 해야한다면?

15. 인덱스 통계를 수집하거나 갱신한다면?

16. 파티셔닝된 테이블에서 인덱스 설계 시 주의점은?

17. covering index란 무엇이고 실무에서 어떻게 활용되나요?

18. 쿼리 튜닝에서 인덱스를 제거해야하는 경우는?

19. 정규화된 테이블에서 JOIN과 인덱스 관계는 어떻게 설계해야 할까요?

20. 실시간 검색 API에서 인덱스 튜닝 전략은 무엇인가요?