인덱스를 만들면 왜 항상 빨라지지 않을까? 후보 찾기와 실행 계획

Об этом предложении

책의 색인처럼 DB 인덱스도 원하는 행의 후보를 찾는 데 도움을 줍니다. 하지만 책의 대부분을 읽어야 한다면 색인을 왕복하는 일이 더 편하지 않을 수 있습니다. 이번에는 인덱스가 하는 일과 DB가 그것을 선택하는 일 을 구분해보겠습니다. 행을 찾는 보조 구조 PostgreSQL의 기본 B-tree 인덱스는 정렬 가능한 값의 동등·범위 조건을 지원합니다. 실제로 사용할지는 플래너가 비용을 비교해 선택합니다. 모든 조건과 모든 인덱스 종류가 같은 방식으로 동작하는 것은 아닙니다. PostgreSQL 18 인덱스 종류 그림은 조회 경로를 설명하는 모델입니다. 실제 B-tree 높이나 페이지 접근 횟수, 측정 시간을 나타내지 않습니다. EXPLAIN에서 달라지는 표시 보기 독립 SQLite 메모리 DB 에 합성 데이터 1,000행을 넣고 다음 SQL을 실행했습니다. PostgreSQL의 실행 계획을 테스트한 결과는 아닙니다. CREATE TABLE item (id INTEGER PRIMARY KEY, category INTEGER); WITH RECURSIVE seq(n) AS ( SELECT 0 UNION ALL SELECT n + 1 FROM seq WHERE n < 999 ) INSERT INTO item (id, category) SELECT n, n % 10 FROM seq; EXPLAIN QUERY PLAN SELECT id FROM item WHERE category = 7; CREATE INDEX item_category_idx ON item(category); EXPLAIN QUERY PLAN SELECT id FROM item WHERE category = 7; 이 실험에서는 인덱스 전 계획에 SCAN item , 생성 후 계획에 SEARCH item USING COVERING INDEX item_category_idx 가 표시됐습니다. SQLite 공식 EXPLAIN QUERY PLAN 설명 계획이 바뀐 사실을 확인한 것이지, 실제 실행 시간이 몇 배 줄었음을 측정한 것은 아닙니다. 다른 데이터 분포와 엔진 버전에서는 다른 선택이 가능합니다. 인덱스를 적용하기 전에는 조회 결과가 같은지도 함께 확인해야 합니다. 읽기만 있는 자료구조가 아니다 인덱스는 공간을 사용하고 데이터 변경 때 함께 관리됩니다. 많은 행을 읽는 조건이라면 전체 스캔이 유리할 수 있습니다. 인덱스가 있다고 항상 쓰는 것도, 계획에 인덱스가 나오면 전체 요청이 빨라지는 것도 아닙니다. 반환 행 수, 정렬, 조인과 다른 비용이 남습니다. 여러 열을 묶은 인덱스는 열의 순서와 조건 조합도 검토해야 합니다. 이번 글에서는 단일 열의 후보 검색까지만 다룹니다. 실서비스 인덱스를 만들기 전에 실제 쿼리와 데이터 분포를 기준으로 판단합니다. 확인 문제 인덱스가 있다는 사실과 플래너가 선택했다는 사실은 같을까요? 전체 행의 90%가 필요한 조회에서도 인덱스가 무조건 유리할까요? EXPLAIN 표시가 바뀌었다면 실행 시간이 줄었다고 확정할 수 있을까요? 답과 해설 아닙니다. 실제 실행 계획을 확인합니다. 아닙니다. 전체 스캔과 후보 조회의 비용을 비교해야 합니다. 안 됩니다. 동일한 조건에서 결과와 실행 비용을 별도로 측정해야 합니다. 오늘은 후보 찾기와 실제 행 확인을 나눠 설명해보겠습니다. 내일은 선택되는 행 비율을 바꾸고, 일주일 뒤에는 복합 인덱스의 열 순서와 연결해보면 좋겠습니다. 자료 확인 기준: PostgreSQL 18과 SQLite 공식 문서, 2026-10-04. 메모리 DB 계획·결과 검증이며 운영 DB의 성능 시험은 아닙니다. 예제 검증 환경: Python 3.13.13의 SQLite 3.51.2, 독립 :memory: DB.

Детали предложения

Провайдер

velog

Источник

velog-rss

Балл

54.39

Уверенность

49%