데이터베이스 인덱스는 왜 조회를 빠르게 만들고, 언제 오히려 느려질까? 빠른 답 인덱스는 컬럼 값을 정렬해 둔 탐색 구조라서 테이블 전체를 읽지 않고 검색 범위를 줄일 수 있다. MySQL InnoDB의 세컨더리 인덱스 리프 노드에는 실제 레코드 주소가 아니라 PK 값이 저장된다. 조건에 맞는 데이터가 너무 많으면 인덱스 탐색과 PK 재조회가 반복되어 풀 테이블 스캔보다 느릴 수 있다. 인덱스 설계는 쿼리 모양과 EXPLAIN 의 type , key , rows , Extra 를 함께 보며 검증해야 한다. 목차 시간 흐름으로 이해하기 흐름으로 보기 인덱스가 필요한 이유 B+Tree 인덱스의 조회 흐름 InnoDB 세컨더리 인덱스와 PK 재조회 실행 계획으로 확인하기 인덱스 스캔 방식과 해석 포인트 인덱스가 오히려 느려지는 경우 인덱스 설계에서 자주 생기는 오해 시간 흐름으로 이해하기 조건 분석 WHERE , JOIN , ORDER BY , GROUP BY 에 등장하는 컬럼을 확인한다. → 인덱스 탐색 사용할 수 있는 인덱스가 있으면 루트 노드에서 리프 노드까지 내려간다. → 범위 스캔 리프 노드에서 조건에 맞는 키 범위를 순서대로 읽는다. → 레코드 접근 필요한 컬럼이 인덱스에 없으면 PK로 실제 레코드를 다시 읽는다. → 실행 계획 확인 EXPLAIN 으로 실제 선택된 인덱스와 예상 읽기량을 비교한다. 하나의 조회 쿼리는 보통 조건을 해석하는 단계에서 시작한다. 옵티마이저는 사용할 수 있는 인덱스 후보를 보고, 인덱스를 쓰는 편이 나은지 테이블을 직접 읽는 편이 나은지 비용을 추정한다. 인덱스를 선택했다면 B+Tree의 루트 노드에서 시작해 리프 노드까지 내려가고, 리프 노드에서 필요한 범위를 읽는다. InnoDB의 세컨더리 인덱스를 사용한 조회라면 여기서 끝나지 않을 수 있다. 리프 노드에 저장된 PK 값을 이용해 클러스터형 인덱스를 다시 조회해야 할 수 있기 때문이다. 이 재조회가 많아지면 인덱스를 사용했는데도 기대보다 느린 쿼리가 된...