인덱스는 필요한 행을 찾는 접근 경로다. 읽기를 줄일 수 있지만 저장 공간과 갱신 비용이 든다.
전체 대출에서 책번호 하나의 이력을 찾을 때 loans(book_id) 인덱스가 도움이 될 수 있다. 반대로 대부분의 행을 읽는 집계에서는 순차 스캔이 유리할 수도 있다. 작은 예제 표의 결과를 큰 운영 표의 성능으로 일반화하지 않는다.
INSERT·UPDATE·DELETE 때 관련 인덱스도 유지해야 한다. 실행 계획과 실제 읽기·쓰기 시간, 저장 공간을 함께 보고 선택한다. 검색 조건과 정렬 조건에 맞는 인덱스인지도 확인한다.
- 01 →
질의를 고른다
- 02 →
접근 경로를 비교한다
- 03 →
읽기·쓰기를 측정한다
- 04
유지 비용을 확인한다
같은 상황에서 비교하기
| 개념 | 기준 | 확인할 점 |
|---|---|---|
| 선택적인 검색 | 적은 행을 찾는 상황 | 인덱스 후보를 검토한다 |
| 넓은 집계 | 많은 행을 읽는 상황 | 전체 스캔도 비교한다 |
| 잦은 갱신 | 쓰기 작업이 많은 상황 | 유지 비용을 측정한다 |
도서관 예제로 따라가기
CREATE INDEX loans_book_idx ON loans(book_id);인덱스 생성이 성공했다는 사실은 측정한 성능 향상과 다르다. 이 자료에서는 구조를 만들 수 있는지만 실행해 확인한다.
공통 예제 데이터 보기
| book_id | title | shelf_code | pages |
|---|---|---|---|
| 1 | SQL 입문 | DB | 120 |
| 2 | 설계 노트 | SW | 200 |
| 3 | 관계 모델 | DB | NULL |
| 4 | 분산 읽기 | NULL | 160 |
| loan_id | book_id |
|---|---|
| 11 | 1 |
| 12 | 1 |
| 13 | 2 |
내 말로 설명해 보기
인덱스 추가 여부를 판단할 때 읽기 속도 외에 무엇을 확인해야 할까?
설명 예시 확인
쓰기 때 유지 비용과 저장 공간, 실제 질의의 실행 계획을 확인한다.