검색 속도가 100배 빨라지는 마법: 데이터베이스 인덱스(Index) 완벽 정리
1. 서론: 책의 '찾아보기'와 데이터베이스
우리가 두꺼운 전공 서적에서 특정 키워드를 찾을 때, 첫 페이지부터 마지막 페이지까지 넘기며 찾지는 않습니다. 보통 책의 가장 뒤에 있는 '찾아보기(Index)' 페이지를 확인해 해당 내용이 있는 쪽수로 바로 이동하죠. 데이터베이스도 마찬가지입니다. 수백만 건의 데이터 속에서 내가 원하는 정보를 눈 깜짝할 새에 찾아내는 기술, 바로 **인덱스(Index)**에 대해 알아보겠습니다.
2. 인덱스의 핵심 원리: B-Tree 알고리즘
데이터베이스 인덱스는 대부분 B-Tree(Balanced Tree) 자료구조를 기반으로 작동합니다.
작동 방식: 데이터를 정렬된 상태로 유지하며, 이진 탐색과 유사하게 탐색 범위를 절반씩 줄여나갑니다.
효율성: 수천만 개의 로우(Row)가 있어도 단 몇 번의 노드 이동만으로 원하는 데이터에 도달할 수 있습니다. 이는 앞서 배운 **시간 복잡도 관점에서 O(log n)**의 성능을 보장합니다.
3. 인덱스가 무조건 좋은 걸까? (Trade-off)
인덱스는 검색 속도를 비약적으로 높여주지만, 공짜는 아닙니다.
저장 공간: 인덱스 자체가 별도의 저장 공간을 차지합니다.
CUD 성능 저하: 데이터가 추가(Insert), 수정(Update), 삭제(Delete)될 때마다 인덱스도 매번 다시 정렬하고 갱신해야 하므로 쓰기 성능은 오히려 떨어집니다.
결론: 무분별한 인덱스 생성은 오히려 독이 될 수 있습니다.
4. 인덱스를 타지 않는 쿼리: 왜 내 인덱스는 무시당할까?
인덱스를 만들어도 정작 실행 계획을 보면 **Full Table Scan(전체 스캔)**을 하는 경우가 있습니다.
인덱스 컬럼 가공:
WHERE YEAR(create_date) = 2024처럼 컬럼을 함수로 감싸면 인덱스를 사용하지 못합니다.OR 조건: 인덱스가 없는 컬럼과 OR로 묶이면 인덱스 탐색이 취소될 수 있습니다.
LIKE 전방 일치:
LIKE '%keyword'처럼 앞에 와일드카드가 붙으면 인덱스를 활용할 수 없습니다.
5. 실무 경험 사례: "쿼리 하나로 서버 멈춤 현상을 해결하다"
[나의 개발 경험: 인덱스 하나로 응답 시간을 10초에서 0.1초로]
예전에 커뮤니티 서비스를 운영할 때, 특정 게시판의 리스트를 불러오는 속도가 점점 느려지는 이슈가 있었습니다. 데이터가 50만 건을 넘어가면서부터 목록을 한 번 불러오는 데 10초 이상 걸렸고, 사용자들은 '서버가 터졌다'며 항의하기 시작했습니다.
실행 계획(EXPLAIN)을 확인해 보니, 게시글을
category_id와created_at순으로 조회하는데 적절한 **복합 인덱스(Composite Index)**가 걸려있지 않아 DB가 50만 건을 매번 처음부터 끝까지 다 읽고(Full Table Scan) 정렬까지 하고 있었습니다.저는 즉시 두 컬럼을 묶는 복합 인덱스를 생성했습니다. 결과는 놀라웠습니다. 10초 넘게 걸리던 쿼리가 0.1초 미만으로 줄어들었습니다. 인덱스라는 '지름길'을 열어준 것만으로 서버의 CPU 점유율이 80%에서 10%대로 떨어지는 것을 보며, DB 튜닝의 중요성을 뼈저리게 실감했습니다.
6. 결론: 개발자의 필수 역량, 쿼리 최적화
현대의 백엔드 개발자에게 DB 인덱스 이해는 선택이 아닌 필수입니다. 내가 짠 코드 한 줄이 DB에 어떤 부하를 주는지 이해하고, 적재적소에 인덱스를 배치하는 것만으로도 서비스의 질을 완전히 바꿀 수 있습니다. 오늘 포스팅이 여러분의 '느린 쿼리'를 고치는 실마리가 되었길 바랍니다.
댓글
댓글 쓰기