Special Index

B-Tree가 아닌 선택지는 목적이 분명해야 한다

특수 인덱스는 “더 빠르게”가 아니라 검색 방식, 대상 행, DBMS 지원이 맞을 때만 고른다.

선택지

맞는 상황

먼저 확인할 제약

Bitmap

값 종류가 적고 여러 조건을 AND/OR로 묶는 분석 조회

잦은 INSERT/UPDATE가 있으면 갱신 비용이 커질 수 있음

Partial / Filtered

활성 행, 미처리 행처럼 일부 데이터만 반복 조회

조건식이 쿼리와 정확히 맞아야 선택됨

Full-text

단어, 토큰, 형태소 기준으로 문서를 찾는 검색

LIKE 대체용이지 정렬/범위 조건의 범용 해법은 아님

Expression

UPPER(name), DATE(created_at)처럼 표현식 결과로 필터링

쿼리의 표현식과 인덱스 정의가 달라지면 활용이 제한됨

Invisible

삭제 후보 인덱스를 실제 제거 전 운영에서 검증

지원 DBMS와 옵티마이저 동작 차이를 확인해야 함

선택 순서 조회 패턴을 먼저 고정하고, 지원 기능을 확인한 뒤, 쓰기 비용과 운영 리스크를 비교한다.

금지 신호 DBMS가 제공한다는 이유만으로 추가하거나, B-Tree 설계 문제를 특수 인덱스로 덮지 않는다.