CS9 Index Merge 1️⃣ Index Merge란?Index Merge는 MySQL/MariaDB 옵티마이저가:“단일 인덱스로는 최적화가 안 되니까여러 인덱스를 각각 타서결과를 합쳐보자”라고 판단했을 때 선택하는 실행 계획이다.EXPLAIN에 보통 이렇게 나타난다.type: index_mergeExtra: Using intersect(...)2️⃣ 옵티마이저가 Index Merge를 선택하는 상황테이블에 이런 인덱스가 있을 때-- 인덱스IDX_A (COMPCD)IDX_B (YEARXX)-- 쿼리WHERE COMPCD = ? AND YEARXX = ?단일 복합 인덱스 ❌두 개의 단일 인덱스만 존재👉 옵티마이저는:COMPCD 인덱스 스캔YEARXX 인덱스 스캔두 결과의 교집합 계산3️⃣ 왜 느린가? (핵심 이유 5가지)① .. 2026. 1. 6. Covering Index (커버링 인덱스) 1️⃣ Covering Index란?쿼리에 필요한 모든 컬럼이인덱스 안에 이미 들어 있어서테이블을 아예 읽지 않아도 되는 상태즉,인덱스 탐색 ✔테이블(Row) 접근 ❌2️⃣ 왜 테이블 접근이 그렇게 비싼가?InnoDB 기준으로 보면:인덱스(B+Tree) → PK 값만 있음실제 데이터는 → Clustered Index(테이블) 에 있음그래서 보통 쿼리는:인덱스 탐색 → PK 추출 → 테이블에서 PK로 다시 조회 (Random I/O)Covering Index는 두번째 단계를 완전히 제거한다. 3️⃣ 예제❌ 일반 인덱스-- 인덱스(COMPCD, PLCBUS, YEARXX, DOCSEQ)-- 쿼리SELECT *FROM HERGMTWHERE COMPCD = ? AND PLCBUS = ? AND YEARX.. 2026. 1. 6. 인덱스 설계 사고방식 2 https://hwk99.tistory.com/214 인덱스 설계 사고방식 1 (GPT 추천 문제)복합 인덱스 설계 사고방식WHERE / ORDER BY / GROUP BY 실행 흐름 기준으로 이해하기최근 GPT에게 “2025년 채팅 기록 기반으로 내가 좋아할 만한 CS 문제를 하나 내봐” 라고 프롬프팅해봤다.그 결과로hwk99.tistory.com 복합 인덱스 설계 사고방식 2BETWEEN / LIKE / IN 이 들어오면 인덱스는 어떻게 깨지는가앞선 글에서는WHERE의 동등 조건(=) + ORDER BY / GROUP BY 기준으로복합 인덱스 순서를 어떻게 잡아야 하는지를 정리했다.이번에는 실무에서 인덱스를 망가뜨리는 주범인BETWEEN, , LIKE, IN 이 등장했을 때인덱스 설계 사고방식이 어떻.. 2026. 1. 6. 인덱스 설계 사고방식 1 복합 인덱스 설계 사고방식WHERE / ORDER BY / GROUP BY 실행 흐름 기준으로 이해하기최근 GPT에게 “2025년 채팅 기록 기반으로 내가 좋아할 만한 CS 문제를 하나 내봐” 라고 프롬프팅해봤다.그 결과로 나온 주제가 꽤 흥미로웠다.복합 인덱스 진짜 쓰는 법WHERE / ORDER BY / GROUP BY 실행 흐름 기준으로인덱스 순서가 왜 중요한지 설명할 수 있는가?아래는 그 문제를 실제 쿼리 기준으로 정리한 내용이다.SELECT *FROM HERGMTWHERE COMPCD = ? -- 회사코드 AND PLCBUS = ? -- 부서코드 AND YEARXX = ? -- 년도ORDER BY DOCSEQ DESCLIMIT 30;이 쿼리를 빠르게 처리하기 위해 아래와 같은 인덱.. 2026. 1. 6. 이전 1 2 3 다음