DB 쿼리 속도 100배 향상

📌 이 글의 핵심 내용

  • 인덱스의 내부 자료구조 B-Tree의 작동 원리와 시간 복잡도
  • Clustered Index와 Non-Clustered Index의 결정적 차이
  • 인덱스를 걸어도 효과가 없는 경우 (카디널리티의 중요성)
  • 복합 인덱스 설계 시 컬럼 순서 결정 법칙 (Leftmost Prefix)
  • 테이블 조회 없이 인덱스만으로 끝내는 커버링 인덱스(Covering Index)

서비스 초기에는 사용자가 적어 쿼리 튜닝의 필요성을 느끼지 못합니다. 하지만 데이터가 수십만, 수백만 건으로 늘어나는 순간, 0.1초 걸리던 조회 쿼리가 3초, 10초로 느려지며 서비스 전체의 병목(Bottleneck)이 됩니다. 이때 가장 먼저 살펴봐야 할 것이 바로 인덱스(Index)입니다.

하지만 무턱대고 모든 컬럼에 인덱스를 걸면 오히려 쓰기(Insert/Update/Delete) 성능이 심각하게 저하됩니다. 인덱스는 공짜가 아닙니다. 정확한 원리를 알고 필요한 곳에만 전략적으로 사용해야 합니다.

데이터베이스 B-트리

1. 인덱스의 기본 원리: B-Tree

데이터베이스 테이블은 기본적으로 데이터가 들어온 순서대로 저장됩니다(Heap Table). 책으로 치면 페이지 번호 없이 내용만 무작위로 적힌 공책과 같습니다. 여기서 특정 단어를 찾으려면 첫 페이지부터 끝까지 다 읽어야 합니다. 이를 Full Table Scan이라 하며, 시간 복잡도는 O(N)입니다.

인덱스를 생성하면 DB는 데이터를 정렬하여 별도의 자료구조인 B-Tree(Balanced Tree)를 구성합니다.

💡 B-Tree의 핵심 특징

루트(Root)에서 리프(Leaf) 노드까지의 거리가 항상 일정하여, 데이터 양이 늘어나도 검색 성능이 급격히 떨어지지 않습니다. 탐색 시간 복잡도는 O(log N)입니다. 데이터가 100만 건일 때, Full Scan은 100만 번 비교해야 하지만, B-Tree는 약 20번의 비교만으로 데이터를 찾을 수 있습니다.

2. Clustered vs Non-Clustered Index

MySQL(InnoDB) 기준으로 인덱스는 크게 두 가지로 나뉩니다. 이 둘의 차이를 아는 것이 튜닝의 첫걸음입니다.

① Clustered Index (군집 인덱스)

  • 책의 페이지 번호와 같습니다. 데이터 자체가 인덱스 순서대로 물리적으로 정렬되어 저장됩니다.
  • 테이블당 단 하나만 존재할 수 있습니다. (물리적 정렬은 하나만 가능하니까요)
  • 주로 Primary Key(PK)가 이 역할을 합니다.
  • 리프 노드에 실제 데이터(모든 컬럼)가 저장되어 있어 조회 속도가 가장 빠릅니다.

② Non-Clustered Index (보조 인덱스)

  • 책의 맨 뒤에 있는 '찾아보기(색인)'와 같습니다.
  • 테이블당 여러 개를 만들 수 있습니다.
  • 리프 노드에는 실제 데이터가 아니라, 데이터의 위치(PK 값)가 저장되어 있습니다.
  • 따라서 데이터를 찾으려면 인덱스 검색 → PK 획득 → PK로 다시 실제 테이블 조회라는 두 번의 과정을 거칩니다.

3. 인덱스를 걸어도 느린 이유: 카디널리티(Cardinality)

"모든 WHERE 조건 컬럼에 인덱스를 걸면 빨라질까요?" 절대 아닙니다. 인덱스 효율의 핵심 지표는 카디널리티(기수성)입니다. 카디널리티란 '데이터의 중복 수치'를 의미합니다.

컬럼 예시 중복도 카디널리티 인덱스 효율
주민번호, ID 없음 (Unique) 매우 높음 최상 👍
이름, 생일 가끔 중복 보통 좋음
성별 (남/여) 50% 중복 매우 낮음 최악 👎

예를 들어, 성별 컬럼에 인덱스를 걸고 '남'을 조회하면 전체 데이터의 50%를 가져와야 합니다. DB 옵티마이저는 "이럴 바엔 그냥 인덱스 안 타고 전체를 훑는 게 더 빠르겠다"라고 판단하여 인덱스를 무시(Full Scan)해 버립니다. 즉, 인덱스를 건 의미가 사라집니다.

따라서 전체 데이터의 10~15% 이하를 걸러낼 수 있는 컬럼에만 인덱스를 거는 것이 유리합니다.

4. 복합 인덱스(Composite Index) 설계 공식

실무에서는 하나의 컬럼으로 조회하기보다 WHERE A = ? AND B = ? 처럼 여러 조건을 조합하는 경우가 많습니다. 이때 사용하는 것이 복합 인덱스입니다. 복합 인덱스는 순서가 생명입니다.

공식 1: Leftmost Prefix Rule (좌측 접두사 규칙)

인덱스를 (A, B, C) 순서로 생성했다고 가정합시다.

-- 인덱스 사용 가능 (O) WHERE A = ? WHERE A = ? AND B = ? WHERE A = ? AND B = ? AND C = ? -- 인덱스 사용 불가 (X) - A가 없어서 시작점을 못 찾음 WHERE B = ? WHERE C = ? WHERE B = ? AND C = ? -- 일부만 사용 가능 (△) - A만 인덱스를 타고 C는 필터링됨 WHERE A = ? AND C = ?

공식 2: 카디널리티가 높은 순서대로

여러 컬럼 중 중복이 적은(더 많이 걸러내는) 컬럼을 앞쪽에 배치하는 것이 성능상 유리합니다. 예를 들어 지역(서울/부산...)과 주민번호가 있다면, 당연히 (주민번호, 지역) 순으로 거는 것이 압도적으로 빠릅니다.

5. 고급 기법: 커버링 인덱스 (Covering Index)

인덱스 튜닝의 꽃입니다. 쿼리에 필요한 모든 컬럼이 인덱스에 포함되어 있어서, 실제 데이터 테이블을 찌르지(Random Access) 않고 인덱스만 읽고 끝내는 방식입니다.

-- 인덱스: (email, username) -- 커버링 인덱스 성공! (인덱스에 email과 username이 다 있음) SELECT email, username FROM users WHERE email = 'test@example.com'; -- 커버링 인덱스 실패 (address는 인덱스에 없음 -> 실제 테이블 조회 발생) SELECT email, address FROM users WHERE email = 'test@example.com';

페이징 쿼리 등에서 성능을 극한으로 끌어올려야 할 때, 일부러 조회하려는 컬럼들을 모두 포함하는 복합 인덱스를 만들기도 합니다.

6. 주의사항: 인덱스를 망치는 쿼리 패턴

아무리 인덱스를 잘 걸어도 쿼리를 잘못 짜면 무용지물입니다.

  • 가공된 컬럼: WHERE YEAR(date) = 2024 처럼 컬럼을 함수로 감싸면 인덱스가 깨집니다. WHERE date >= '2024-01-01'로 써야 합니다.
  • 부정 연산: !=, NOT IN 등은 인덱스를 타지 못할 확률이 높습니다.
  • LIKE 앞쪽 와일드카드: LIKE '%abc'는 시작점을 알 수 없어 Full Scan을 합니다. LIKE 'abc%'는 인덱스를 탑니다.
  • 데이터 타입 불일치: 문자열 컬럼을 숫자로 조회하면 내부 형변환이 일어나 인덱스가 깨집니다.

7. 결론

인덱스는 조회 속도를 높여주는 강력한 무기지만, 쓰기 성능과 저장 공간(디스크)을 담보로 하는 거래입니다. 무조건 많이 거는 것이 능사가 아니며, EXPLAIN 명령어를 통해 쿼리 실행 계획을 확인하는 습관을 들여야 합니다.

데이터베이스 성능 최적화는 "디스크 I/O를 얼마나 줄이느냐"의 싸움임을 기억하십시오.

이 블로그의 인기 게시물

Docker 컨테이너 'Connection Refused' (Errno 111) 오류 해결 가이드

이미지
🎯 타겟 독자: Docker 입문자, 컨테이너를 띄웠으나 localhost 로 접속이 안 되는 백엔드 개발자, MSA(마이크로서비스) 구축 중 통신 오류를 겪는 엔지니어. 📝 요약: Docker 접속 오류(Errno 111)의 90%는 애플리케이션이 '0.0.0.0'이 아닌 '127.0.0.1' 로 바인딩 되어 있거나, 포트 포워딩(-p) 설정이 누락되어 발생합니다. 이 글에서는 네트워크 인터페이스의 차이를 이해하고, 외부 접속을 허용하는 올바른 설정법을 정리합니다. 1. 문제 정의: "컨테이너는 떴는데 접속이 안 돼요" Docker 입문자들이 가장 흔하게 겪는 상황입니다. docker ps 로 확인하면 상태(STATUS)는 분명히 Up 인데, 브라우저나 Postman으로 접속하면 즉시 연결이 거부됩니다. curl: (7) Failed to connect to localhost port 8080: Connection refused Python: ConnectionRefusedError: [Errno 111] Connection refused 이 문제는 방화벽 때문이 아닙니다. "누구의 요청을 들을 준비가 되었는가(Listen Address)" 에 대한 설정이 잘못되었기 때문입니다. 2. 원인 분석: 127.0.0.1의 함정 핵심은 Loopback(127.0.0.1) 과 Any Address(0.0.0.0) 의 차이입니다. 로컬 PC에서 개발할 때 서버를 localhost 로 띄우는 건 보안상 좋은 습관입니다. 하지만 Docker 컨테이너는 독립된 IP를 ...
자세한 내용 보기

Redis 캐싱 전략 완벽 가이드: Look Aside부터 Write Back까지 (DB 부하 줄이기)

이미지
🎯 타겟 독자: 사용자가 몰릴 때마다 DB CPU가 100%를 치는 상황을 겪는 백엔드 개발자, Redis를 단순히 get/set 으로만 쓰고 있는 주니어 엔지니어. 📝 요약: 캐시(Cache)는 성능 향상의 치트키지만, 잘못 쓰면 데이터 불일치(Inconsistency) 라는 재앙을 부릅니다. 이 글에서는 가장 대중적인 Look Aside(Lazy Loading) 패턴과 쓰기 성능을 극대화하는 Write Back 패턴의 작동 원리, 장단점, 그리고 언제 무엇을 써야 하는지 명확한 기준을 제시합니다. 1. 캐싱 패턴이 왜 중요한가요? "그냥 Redis에 넣으면 되는 거 아닌가요?"라고 묻는다면 반은 맞고 반은 틀립니다. 캐시를 데이터베이스(DB)와 어떤 순서로 연동하느냐에 따라 시스템의 데이터 정합성 과 성능 이 완전히 달라지기 때문입니다. 2. 패턴 ① Look Aside (Lazy Loading) - 국룰 전략 현업에서 80% 이상 사용되는 가장 일반적인 읽기 전략입니다. 캐시를 옆(Aside)에 두고 필요할 때만 데이터를 가져옵니다. 작동 순서 앱이 데이터를 찾을 때 먼저 캐시(Redis)를 찌릅니다. 캐시에 데이터가 있으면(Cache Hit) 바로 반환합니다. (DB 부하 0) 없으면(Cache Miss) DB에서 조회 하여 가져옵니다. 가져온 데이터를 캐시에 저장 하고 반환합니다. public User getUser(Long id) { // 1. 캐시 조회 User user = redisTemplate.opsForValue().get("user:" +...
자세한 내용 보기

브라우저 렌더링 원리: Reflow와 Repaint 최적화 가이드 (CRP 심층 분석)

이미지
📌 핵심 요약 CRP(Critical Rendering Path) 의 5단계: DOM → CSSOM → Render Tree → Layout → Paint 성능의 주범 Reflow(Layout) 와 Repaint 의 차이점 애니메이션 성능 최적화: 왜 top/left 대신 transform 을 써야 하는가? (GPU 가속과 Composite) "사용자가 주소창에 URL을 입력하고 엔터를 쳤을 때, 화면에 네이버 메인이 뜨기까지 무슨 일이 일어나는가?" 이 질문은 네트워크 관점(DNS, TCP/IP)에서도 답변할 수 있지만, 프론트엔드 개발자라면 렌더링 엔진(Rendering Engine)이 HTML과 CSS를 해석해서 픽셀로 바꿔주는 과정, 즉 CRP(Critical Rendering Path)를 설명할 수 있어야 합니다. 이 원리를 알아야 "왜 리액트가 Virtual DOM을 쓰는지", "왜 애니메이션이 버벅이는지" 이해할 수 있습니다. 1. 렌더링 파이프라인 (The Pipeline) 브라우저는 다음 5단계를 거쳐 화면을 그립니다. DOM 트리 생성: HTML 문서를 파싱 하여 태그 간의 관계(부모-자식)를 트리 구조로 만듭니다. CSSOM 트리 생성: CSS 파일과 인라인 스타일을 파싱 하여 스타일 규칙 트리를 만듭니다. Render Tree 생성: DOM과 CSSOM을 결합하여 "실제로 화면에 표시될 노드" 만 추려냅니다. Layout (Reflow): 각 노드가 화면의 어느 위치에, 어떤 크기(px) 로 배치될지 기하학적 계산을 수행합니다. ...
자세한 내용 보기