← 질문 목록
#187깊이 0
인덱스 생성 시 읽기 성능과 쓰기 성능의 트레이드오프는 무엇인가?
답변 연습
내 답변 적어보기접힘
이 브라우저에 자동 저장 · 0자
모범답안 확인하기내 답변 뒤에 열어보세요
인덱스는 자주 찾는 조건으로 후보 행을 빨리 좁히는 대신 쓰기와 저장 공간을 더 쓴다. 있다는 이유만으로 모든 읽기가 빨라지지는 않는다.
| 확인할 것 | 읽기에서 얻는 것 | 쓰기에서 치르는 것 |
|---|---|---|
| 검색 조건·정렬 | 맞는 연산과 열 순서면 읽을 범위가 줄어든다 | 해당 인덱스 항목도 함께 고친다 |
| 선택도 | 일부 행만 찾을수록 유리하다 | 낮은 선택도의 인덱스도 계속 유지한다 |
| 포함 열 | 테이블 방문을 줄일 수 있다 | 인덱스가 커져 캐시와 저장 공간을 쓴다 |
B-tree는 동등 비교와 범위·정렬에 주로 맞는다. 복합 B-tree는 앞쪽 열의 조건이 탐색 범위를 줄이는 데 특히 중요하다. 배열 포함이나 공간 검색처럼 연산이 다르면 다른 인덱스 종류가 필요할 수 있다.
INSERT와 DELETE는 관련 인덱스를 유지한다. UPDATE도 인덱스 열을 바꾸면 새 항목을 써야 한다.
PostgreSQL에서는 인덱스가 많으면 heap-only tuple 최적화를 막을 수도 있다. 페이지 분할은 생길 수 있는 비용이지 모든 삽입마다 일어나는 과정은 아니다.
결정은 인덱스 개수의 감으로 하지 않는다. 실제 크기와 값 분포에서 EXPLAIN ANALYZE로 계획과 실행 시간을 본다. 사용 빈도·쓰기 지연·인덱스 크기도 함께 재고 거의 쓰이지 않는 인덱스는 제거한다.