[DB] 데이터베이스 개념노트 16편 - 인덱스(Index)

데이터베이스 개념노트 16편 - 인덱스(Index)

지난 글에서는 데이터베이스 작업의 안정성을 보장하는 트랜잭션과 ACID에 대해 정리했습니다.

이번 글에서는 SQL 성능에서 매우 중요한 개념인 인덱스(Index)에 대해 정리해 보겠습니다.

인덱스는 데이터를 더 빠르게 찾기 위해 사용하는 데이터베이스 객체입니다. SQLD에서도 인덱스의 개념, 장단점, 생성 기준, 주의사항은 자주 등장하므로 반드시 이해해 두는 것이 좋습니다.

---

1. 인덱스란?

인덱스(Index)는 테이블에서 원하는 데이터를 빠르게 찾기 위해 사용하는 객체입니다.

인덱스는 테이블의 데이터를 빠르게 검색하기 위해 특정 컬럼을 기준으로 만들어 둔 검색 구조이다.

책의 목차나 색인을 생각하면 이해하기 쉽습니다. 책에서 원하는 내용을 찾을 때 처음부터 끝까지 모든 페이지를 읽는 대신, 목차나 색인을 보고 해당 페이지로 바로 이동할 수 있습니다.

데이터베이스의 인덱스도 비슷합니다. 테이블 전체를 처음부터 끝까지 모두 읽지 않고, 인덱스를 이용해 원하는 데이터가 있는 위치를 빠르게 찾을 수 있습니다.

---

2. 인덱스가 필요한 이유

테이블에 데이터가 적을 때는 전체 데이터를 읽어도 큰 문제가 없습니다. 하지만 데이터가 수십만 건, 수백만 건, 수천만 건으로 늘어나면 원하는 데이터를 찾는 데 시간이 오래 걸릴 수 있습니다.

예를 들어 회원 테이블에 1,000만 명의 회원 정보가 있다고 가정해 보겠습니다. 특정 이메일을 가진 회원을 찾기 위해 모든 행을 하나씩 확인하면 비효율적입니다.

SELECT *
FROM 회원
WHERE 이메일 = 'jihoon@example.com';

이메일 컬럼에 인덱스가 있다면 데이터베이스는 이메일 값을 기준으로 빠르게 해당 회원을 찾을 수 있습니다.

---

3. 인덱스 비유

비유	데이터베이스	설명
책 본문	테이블	실제 데이터가 저장된 곳
책의 색인	인덱스	원하는 내용을 빠르게 찾기 위한 구조
페이지 번호	데이터 위치 정보	실제 데이터가 있는 위치

인덱스는 실제 데이터를 복사해서 모두 저장하는 것이 아니라, 검색에 필요한 컬럼 값과 해당 데이터 위치 정보를 관리합니다.

---

4. 인덱스가 없을 때

인덱스가 없으면 데이터베이스는 조건에 맞는 데이터를 찾기 위해 테이블 전체를 읽을 수 있습니다. 이를 Full Table Scan이라고 합니다.

Full Table Scan은 테이블의 모든 행을 처음부터 끝까지 읽는 방식이다.

SELECT *
FROM 회원
WHERE 회원번호 = 1001;

회원번호에 인덱스가 없다면 데이터베이스는 회원번호가 1001인 행을 찾기 위해 전체 테이블을 확인할 수 있습니다.

---

5. 인덱스가 있을 때

회원번호에 인덱스가 있다면 데이터베이스는 인덱스를 먼저 확인합니다. 그리고 인덱스에서 회원번호 1001의 위치를 찾은 뒤, 실제 테이블 데이터에 접근합니다.

CREATE INDEX IDX_회원_회원번호
ON 회원(회원번호);

이후 다음 SQL을 실행하면 인덱스를 활용할 수 있습니다.

SELECT *
FROM 회원
WHERE 회원번호 = 1001;

인덱스를 사용하면 전체 테이블을 모두 읽지 않아도 되므로 검색 속도가 빨라질 수 있습니다.

---

6. 인덱스 생성 문법

인덱스는 CREATE INDEX 문으로 생성할 수 있습니다.

CREATE INDEX 인덱스명
ON 테이블명(컬럼명);

예를 들어 회원 테이블의 이메일 컬럼에 인덱스를 만들면 다음과 같습니다.

CREATE INDEX IDX_회원_이메일
ON 회원(이메일);

인덱스 이름은 보통 어떤 테이블의 어떤 컬럼에 대한 인덱스인지 알아보기 쉽게 작성합니다.

---

7. 인덱스 삭제 문법

인덱스를 삭제할 때는 DROP INDEX를 사용합니다.

DROP INDEX IDX_회원_이메일;

인덱스를 삭제해도 테이블의 데이터는 삭제되지 않습니다. 다만 해당 인덱스를 이용한 검색 성능 개선 효과는 사라질 수 있습니다.

---

8. 기본키와 인덱스

기본키를 생성하면 DBMS는 일반적으로 기본키 컬럼에 인덱스를 자동으로 생성합니다.

CREATE TABLE 회원 (
  회원번호 NUMBER PRIMARY KEY,
  이름 VARCHAR2(50),
  이메일 VARCHAR2(100)
);

위 예시에서 회원번호는 기본키입니다. 기본키는 각 행을 유일하게 식별해야 하므로, 데이터베이스는 회원번호를 빠르게 찾기 위한 인덱스를 생성할 수 있습니다.

UNIQUE 제약조건을 생성할 때도 중복 여부를 빠르게 확인하기 위해 인덱스가 함께 생성될 수 있습니다.

---

9. 인덱스의 장점

인덱스의 가장 큰 장점은 검색 성능 향상입니다.

• WHERE 조건 검색 속도를 높일 수 있다.
• JOIN 조건 처리에 도움을 줄 수 있다.
• ORDER BY 정렬 성능에 도움을 줄 수 있다.
• GROUP BY 처리에 도움을 줄 수 있다.
• 기본키와 유니크 제약조건의 중복 검사를 빠르게 할 수 있다.

특히 데이터가 많은 테이블에서 특정 조건으로 일부 데이터만 자주 조회한다면 인덱스가 큰 도움이 될 수 있습니다.

---

10. 인덱스의 단점

인덱스는 장점만 있는 것은 아닙니다. 인덱스를 만들면 별도의 저장 공간이 필요하고, 데이터 변경 작업에는 추가 비용이 발생합니다.

• 인덱스를 저장하기 위한 추가 공간이 필요하다.
• INSERT 시 인덱스에도 새 값을 반영해야 한다.
• UPDATE 시 인덱스 컬럼 값이 바뀌면 인덱스도 수정해야 한다.
• DELETE 시 인덱스에서도 해당 정보를 제거해야 한다.
• 인덱스가 너무 많으면 오히려 성능이 저하될 수 있다.

즉, 인덱스는 SELECT 성능을 높이는 데 도움이 될 수 있지만, INSERT, UPDATE, DELETE 성능에는 부담이 될 수 있습니다.

---

11. 인덱스를 만들면 좋은 컬럼

인덱스는 아무 컬럼에나 많이 만든다고 좋은 것이 아닙니다. 인덱스를 만들면 효과가 좋은 컬럼이 있습니다.

컬럼 특징	인덱스 효과	예시
WHERE절에 자주 사용되는 컬럼	조건 검색 속도 향상	회원번호, 이메일
JOIN 조건에 자주 사용되는 컬럼	테이블 연결 성능 향상 가능	회원번호, 주문번호
값의 종류가 많은 컬럼	특정 값 검색에 유리	회원번호, 이메일, 주문번호
정렬에 자주 사용되는 컬럼	ORDER BY 성능 향상 가능	가입일, 주문일자

값의 종류가 많고, 조건 검색에 자주 사용되는 컬럼일수록 인덱스 효과가 좋을 가능성이 높습니다.

---

12. 인덱스 효과가 낮을 수 있는 컬럼

반대로 인덱스를 만들어도 효과가 낮을 수 있는 컬럼도 있습니다.

컬럼 특징	이유	예시
값의 종류가 적은 컬럼	많은 행이 같은 값을 가지므로 검색 범위가 넓음	성별, 사용여부
자주 변경되는 컬럼	UPDATE 시 인덱스 수정 비용 증가	상태값, 수정일시
거의 조회 조건에 사용되지 않는 컬럼	인덱스를 사용할 기회가 적음	비고, 메모
테이블 데이터가 매우 적은 경우	전체 테이블을 읽는 것이 더 빠를 수 있음	코드성 소형 테이블

예를 들어 성별 컬럼은 남, 여처럼 값의 종류가 적기 때문에 일반적인 B-Tree 인덱스 효과가 크지 않을 수 있습니다.

---

13. 선택도와 카디널리티

인덱스를 이해할 때 선택도와 카디널리티 개념을 알아두면 좋습니다.

개념	설명
선택도	조건에 의해 선택되는 데이터의 비율
카디널리티	컬럼 값의 종류가 얼마나 다양한지 나타내는 정도

일반적으로 인덱스는 선택도가 낮고, 카디널리티가 높은 컬럼에서 효과가 좋습니다.

• 선택도가 낮다 : 조건에 맞는 데이터가 적다.
• 카디널리티가 높다 : 컬럼 값의 종류가 많다.

예를 들어 이메일은 대부분 회원마다 다르므로 카디널리티가 높습니다. 이메일로 한 명의 회원을 찾는 조건은 선택도가 낮기 때문에 인덱스 효과가 좋을 수 있습니다.

---

14. B-Tree 인덱스

가장 일반적으로 사용되는 인덱스 구조는 B-Tree 인덱스입니다.

B-Tree 인덱스는 정렬된 트리 구조를 이용해 데이터를 빠르게 검색하는 인덱스 방식이다.

B-Tree 인덱스는 루트, 브랜치, 리프 블록 같은 구조를 통해 원하는 값을 빠르게 찾아갑니다.

• 루트 블록 : 검색의 시작 지점
• 브랜치 블록 : 중간 탐색 지점
• 리프 블록 : 실제 인덱스 값과 데이터 위치 정보가 있는 지점

SQLD에서는 B-Tree의 내부 구조를 깊게 계산하기보다는, 일반적인 검색에 많이 사용되는 대표적인 인덱스 구조라고 이해하면 됩니다.

---

15. 유니크 인덱스

유니크 인덱스(Unique Index)는 인덱스 컬럼에 중복 값을 허용하지 않는 인덱스입니다.

CREATE UNIQUE INDEX IDX_회원_이메일
ON 회원(이메일);

위 SQL은 이메일 컬럼에 중복 값을 허용하지 않는 인덱스를 생성합니다.

유니크 인덱스는 검색 성능뿐만 아니라 데이터 중복을 방지하는 역할도 할 수 있습니다.

---

16. 논유니크 인덱스

논유니크 인덱스(Non-Unique Index)는 중복 값을 허용하는 인덱스입니다.

CREATE INDEX IDX_회원_등급
ON 회원(회원등급);

회원등급은 골드, 실버, 일반처럼 여러 회원이 같은 값을 가질 수 있습니다. 이런 컬럼에 만드는 인덱스는 논유니크 인덱스가 됩니다.

다만 값의 종류가 적은 컬럼은 인덱스 효과가 낮을 수 있으므로 신중하게 검토해야 합니다.

---

17. 단일 컬럼 인덱스

단일 컬럼 인덱스는 하나의 컬럼으로 만든 인덱스입니다.

CREATE INDEX IDX_회원_이메일
ON 회원(이메일);

이 인덱스는 이메일 컬럼을 기준으로 데이터를 빠르게 찾을 때 사용될 수 있습니다.

---

18. 복합 인덱스

복합 인덱스는 두 개 이상의 컬럼을 묶어서 만든 인덱스입니다.

CREATE INDEX IDX_주문_회원번호_주문일자
ON 주문(회원번호, 주문일자);

위 인덱스는 회원번호와 주문일자를 함께 기준으로 만든 인덱스입니다.

복합 인덱스에서는 컬럼 순서가 중요합니다. 앞쪽 컬럼이 조건에 잘 사용될수록 인덱스를 효율적으로 사용할 가능성이 높습니다.

---

19. 복합 인덱스 컬럼 순서

복합 인덱스가 다음과 같이 생성되어 있다고 가정해 보겠습니다.

CREATE INDEX IDX_주문_회원번호_주문일자
ON 주문(회원번호, 주문일자);

이 인덱스는 다음 조건에서 활용될 가능성이 높습니다.

SELECT *
FROM 주문
WHERE 회원번호 = 'M001';

SELECT *
FROM 주문
WHERE 회원번호 = 'M001'
  AND 주문일자 >= TO_DATE('2026-01-01', 'YYYY-MM-DD');

하지만 주문일자만 조건에 있는 경우에는 인덱스를 효율적으로 사용하기 어려울 수 있습니다.

SELECT *
FROM 주문
WHERE 주문일자 >= TO_DATE('2026-01-01', 'YYYY-MM-DD');

복합 인덱스는 앞쪽 컬럼부터 정렬된 구조이기 때문에, 선행 컬럼이 조건에 사용되는지가 중요합니다.

---

20. 함수 기반 인덱스

일반적으로 컬럼에 함수를 적용하면 인덱스를 사용하기 어려울 수 있습니다.

SELECT *
FROM 회원
WHERE LOWER(이메일) = 'jihoon@example.com';

이메일 컬럼에 일반 인덱스가 있어도 LOWER(이메일)처럼 함수가 적용되면 인덱스 사용이 어려울 수 있습니다. 이럴 때 함수 결과를 기준으로 인덱스를 만들 수 있습니다. 이를 함수 기반 인덱스라고 합니다.

CREATE INDEX IDX_회원_이메일_LOWER
ON 회원(LOWER(이메일));

함수 기반 인덱스는 특정 함수 표현식을 조건에서 자주 사용할 때 검토할 수 있습니다.

---

21. 인덱스를 사용하기 어려운 경우

인덱스가 있어도 항상 사용되는 것은 아닙니다. 다음과 같은 경우에는 인덱스 사용이 어려워질 수 있습니다.

상황	예시	이유
컬럼에 함수 사용	WHERE LOWER(이메일) = ...	원래 컬럼 값 기준 인덱스와 비교 어려움
컬럼에 연산 사용	WHERE 포인트 + 100 > 1000	컬럼 값이 변형됨
LIKE 앞에 % 사용	WHERE 이름 LIKE '%훈'	시작 위치를 알 수 없어 탐색 어려움
부정 조건 사용	WHERE 회원등급 <> '일반'	조회 범위가 넓어질 가능성
묵시적 형변환 발생	문자 컬럼을 숫자처럼 비교	컬럼 변환이 발생할 수 있음

---

22. LIKE와 인덱스

LIKE 조건에서는 와일드카드 위치가 중요합니다.

WHERE 이름 LIKE '김%'

위 조건은 김으로 시작하는 이름을 찾는 조건입니다. 문자열의 시작 부분이 정해져 있으므로 인덱스를 사용할 가능성이 있습니다.

WHERE 이름 LIKE '%훈'

위 조건은 훈으로 끝나는 이름을 찾는 조건입니다. 앞부분이 무엇인지 알 수 없으므로 일반적인 인덱스를 사용하기 어려울 수 있습니다.

조건	인덱스 활용 가능성	설명
LIKE '김%'	높음	시작 문자열이 고정됨
LIKE '%훈'	낮음	앞부분을 알 수 없음
LIKE '%지%'	낮음	중간 포함 검색은 범위가 넓음

---

23. 인덱스와 ORDER BY

인덱스는 정렬 성능에도 영향을 줄 수 있습니다. 인덱스는 컬럼 값을 정렬된 구조로 관리하기 때문입니다.

CREATE INDEX IDX_회원_가입일
ON 회원(가입일);

가입일 컬럼에 인덱스가 있을 때 다음 SQL은 정렬 과정에서 인덱스의 도움을 받을 수 있습니다.

SELECT *
FROM 회원
ORDER BY 가입일;

다만 실제 인덱스 사용 여부는 데이터 양, 조건, 옵티마이저 판단 등에 따라 달라질 수 있습니다.

---

24. 인덱스와 DML 성능

인덱스는 SELECT 성능에는 도움이 될 수 있지만, INSERT, UPDATE, DELETE 같은 DML 작업에는 부담을 줄 수 있습니다.

새로운 행을 INSERT하면 테이블뿐만 아니라 관련 인덱스에도 데이터가 추가되어야 합니다. 인덱스 컬럼 값을 UPDATE하면 인덱스도 함께 수정되어야 합니다. DELETE하면 인덱스에서도 해당 정보가 제거되어야 합니다.

DML	인덱스 영향
INSERT	새 인덱스 항목 추가 필요
UPDATE	인덱스 컬럼 변경 시 인덱스 수정 필요
DELETE	인덱스 항목 삭제 필요

따라서 인덱스는 많이 만들수록 좋은 것이 아니라, 조회 성능과 데이터 변경 비용을 함께 고려해야 합니다.

---

25. 인덱스가 많으면 좋은가?

인덱스가 많다고 무조건 좋은 것은 아닙니다. 오히려 너무 많은 인덱스는 데이터 변경 성능을 떨어뜨리고 저장 공간을 낭비할 수 있습니다.

• 조회에는 도움이 될 수 있다.
• 입력, 수정, 삭제에는 부담이 될 수 있다.
• 저장 공간을 추가로 사용한다.
• 사용되지 않는 인덱스는 관리 비용만 증가시킨다.

좋은 인덱스 설계는 자주 사용하는 SQL과 데이터 특성을 분석해서 필요한 곳에 적절히 만드는 것입니다.

---

26. 인덱스 사용 예시

회원 테이블에서 이메일로 회원을 자주 조회한다고 가정해 보겠습니다.

SELECT *
FROM 회원
WHERE 이메일 = 'jihoon@example.com';

이메일은 중복이 거의 없고 WHERE절에 자주 사용되므로 인덱스 후보가 될 수 있습니다.

CREATE INDEX IDX_회원_이메일
ON 회원(이메일);

이제 이메일 조건 검색에서 인덱스를 사용할 가능성이 높아집니다.

---

27. 인덱스 설계 시 고려사항

인덱스를 설계할 때는 다음 내용을 고려하는 것이 좋습니다.

• 해당 컬럼이 WHERE절에 자주 사용되는가?
• JOIN 조건에 자주 사용되는가?
• ORDER BY나 GROUP BY에 자주 사용되는가?
• 컬럼의 카디널리티가 높은가?
• 조건에 의해 선택되는 데이터 비율이 낮은가?
• 데이터 변경이 자주 발생하지 않는가?
• 이미 비슷한 인덱스가 존재하지 않는가?

인덱스는 SQL 성능을 높이는 강력한 도구이지만, 테이블과 SQL 사용 패턴을 고려해서 설계해야 합니다.

---

28. 실행 계획이란?

인덱스가 실제로 사용되는지는 실행 계획을 통해 확인할 수 있습니다.

실행 계획은 DBMS가 SQL을 어떤 방식으로 처리할지 보여주는 실행 경로 정보이다.

예를 들어 데이터베이스가 특정 SQL을 실행할 때 전체 테이블을 읽을지, 인덱스를 사용할지, 어떤 JOIN 방식을 사용할지 등을 실행 계획에서 확인할 수 있습니다.

SQLD에서는 실행 계획을 깊게 튜닝하는 수준까지는 아니더라도, 인덱스가 있다고 항상 사용되는 것은 아니며 DBMS의 옵티마이저가 실행 계획을 선택한다는 점을 이해하면 좋습니다.

---

29. 옵티마이저란?

옵티마이저(Optimizer)는 SQL을 가장 효율적으로 실행하기 위한 방법을 선택하는 DBMS의 핵심 구성 요소입니다.

옵티마이저는 SQL 실행 비용을 고려해 가장 효율적인 실행 계획을 선택하는 역할을 한다.

옵티마이저는 테이블 크기, 인덱스 존재 여부, 데이터 분포, 통계 정보 등을 참고하여 실행 계획을 결정합니다. 따라서 인덱스가 존재해도 옵티마이저가 전체 테이블 스캔이 더 효율적이라고 판단하면 인덱스를 사용하지 않을 수 있습니다.

---

30. 인덱스에서 자주 하는 실수

실수	주의할 점
모든 컬럼에 인덱스를 생성함	저장 공간과 DML 비용이 증가함
값의 종류가 적은 컬럼에 무조건 인덱스를 생성함	인덱스 효과가 낮을 수 있음
자주 변경되는 컬럼에 인덱스를 많이 생성함	UPDATE 성능이 저하될 수 있음
복합 인덱스 컬럼 순서를 고려하지 않음	선행 컬럼 조건이 중요함
인덱스 컬럼에 함수를 사용함	일반 인덱스를 사용하기 어려울 수 있음
LIKE '%문자' 검색에서도 인덱스가 항상 사용된다고 생각함	앞쪽 와일드카드는 인덱스 활용이 어려울 수 있음

---

31. SQLD 관점에서 꼭 기억할 내용

이번 글에서 SQLD 공부를 위해 꼭 기억해야 할 내용은 다음과 같습니다.

• 인덱스는 데이터를 빠르게 검색하기 위한 데이터베이스 객체이다.
• 인덱스는 책의 색인처럼 원하는 데이터를 빠르게 찾도록 도와준다.
• 인덱스는 SELECT 성능 향상에 도움을 줄 수 있다.
• 인덱스는 INSERT, UPDATE, DELETE 성능에는 부담이 될 수 있다.
• 기본키와 유니크 제약조건에는 인덱스가 생성될 수 있다.
• 카디널리티가 높은 컬럼은 인덱스 효과가 좋을 가능성이 높다.
• 값의 종류가 적은 컬럼은 인덱스 효과가 낮을 수 있다.
• 복합 인덱스에서는 컬럼 순서가 중요하다.
• 컬럼에 함수나 연산을 적용하면 인덱스 사용이 어려울 수 있다.
• LIKE에서 앞쪽에 %가 있으면 일반적인 인덱스 활용이 어려울 수 있다.
• 인덱스가 있다고 항상 사용되는 것은 아니며 옵티마이저가 실행 계획을 선택한다.

---

32. 핵심 요약

개념	핵심 내용
인덱스	테이블에서 원하는 데이터를 빠르게 찾기 위한 검색 구조
Full Table Scan	테이블 전체를 처음부터 끝까지 읽는 방식
B-Tree 인덱스	정렬된 트리 구조를 이용하는 대표적인 인덱스
유니크 인덱스	중복 값을 허용하지 않는 인덱스
복합 인덱스	두 개 이상의 컬럼으로 구성된 인덱스
선택도	조건에 의해 선택되는 데이터의 비율
카디널리티	컬럼 값의 종류가 얼마나 다양한지 나타내는 정도
옵티마이저	SQL의 효율적인 실행 계획을 선택하는 DBMS 구성 요소

---

33. 마무리

이번 글에서는 SQL 성능에서 중요한 인덱스에 대해 정리했습니다.

인덱스는 테이블에서 원하는 데이터를 빠르게 찾기 위한 검색 구조입니다. WHERE 조건, JOIN 조건, ORDER BY 등에 적절히 사용되면 SELECT 성능을 크게 높일 수 있습니다.

하지만 인덱스는 추가 저장 공간을 사용하고, INSERT, UPDATE, DELETE 작업에는 부담을 줄 수 있습니다. 따라서 무조건 많이 만드는 것이 아니라, 자주 사용하는 SQL과 데이터 특성을 고려해서 필요한 컬럼에 적절히 생성해야 합니다.

SQLD에서는 인덱스의 장단점, 인덱스가 효과적인 컬럼, 복합 인덱스의 컬럼 순서, 인덱스를 사용하기 어려운 조건을 잘 기억해두면 좋습니다.

다음 글에서는 SELECT문을 더 편리하게 사용할 수 있도록 도와주는 뷰(View)에 대해 정리해 보겠습니다.