인덱스가 "검색을 빠르게 해주는 것" 정도인지, _자료구조·스캔 방식·쓰기 비용_까지 묶어 트레이드오프로 말하는 사람인지를 가른다.
인덱스는 검색 속도를 높이기 위해 컬럼 값을 정렬 구조(주로 B-Tree)에 별도로 저장하는 자료구조다. InnoDB 기준 클러스터드 인덱스 리프에는 행 데이터가, 세컨더리 인덱스 리프에는 _PK_가 저장되어 PK로 다시 찾아가는 "북마크 조회"가 일어날 수 있다. 또한 인덱스 활용은 _레인지 스캔·풀 인덱스 스캔·루스 인덱스 스캔·풀 테이블 스캔_처럼 실행 방식이 다양해, 같은 인덱스라도 쿼리 조건과 카디널리티에 따라 옵티마이저가 다른 경로를 고른다. 즉 인덱스 설계는 _자료구조 + 옵티마이저 동작_을 같이 보는 작업이다.
EXPLAIN을 보고 "인덱스를 안 탄다"의 원인을 카디널리티/타입 캐스팅에서 찾아본 경험이 있다면 그 케이스가 그대로 답변 후크가 된다
복합 인덱스의 컬럼 순서를 재배치해 쿼리 시간이 줄어든 경험이 있다면 _선두 컬럼_ 규칙 이야기로 이어진다
인덱스를 추가했다가 _쓰기 처리량이 떨어진_ 경험이 있다면 트레이드오프를 정량으로 보여줄 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.