데이터베이스 관리시스템(DBMS)·질의·인덱스

원하는 행을 어떻게 찾는가

백만 건의 주문에서 특정 고객의 최근 주문을 찾을 때 모든 행을 처음부터 읽을 수도 있다. 같은 검색을 자주 한다면 찾을 값을 정렬해 둔 별도 길잡이를 이용하는 편이 빠르다. 데이터베이스 성능을 판단하려면 질문을 표현하는 방법과 그 질문이 어떤 접근경로를 쓰는지 함께 봐야 한다.

먼저 되짚기: 영속성과 관계형 구조

영속성은 프로그램이 끝나도 정보를 보존하는 성질이고, 테이블·키·관계는 행을 식별하고 연결하는 관계형 구조다. DBMS와 인덱스는 이 영속 데이터의 구조·질의·접근경로를 관리한다.

데이터베이스

데이터베이스(database, DB)는 일정한 목적에 따라 구조와 의미를 정하고 지속적으로 관리하는 관련 데이터의 집합이다. 주문 DB라면 주문·고객·상품의 값뿐 아니라 각 값의 형식, 키와 관계, 지켜야 할 제약도 관리 대상에 포함된다. DB는 데이터 집합이고, 다음에 정의하는 DBMS는 그 집합을 저장·질의·보호하는 소프트웨어이므로 둘을 같은 뜻으로 쓰지 않는다.

DBMS·질의·인덱스의 정의

데이터베이스 관리시스템(Database Management System, DBMS)은 DB의 구조를 정의하고 저장·질의하며 동시접근, 복구와 보호를 관리하는 소프트웨어다. 즉 DB는 관리 대상 데이터이고 DBMS는 이를 다루는 실행 시스템이다. 질의(query)는 원하는 데이터와 조건·결합·정렬·집계를 표현한 요청이며, 구조화 질의 언어(Structured Query Language, SQL)는 관계형 데이터에서 질의를 표현하고 정의·변경하는 대표 언어다. 인덱스(index)는 검색 기준의 값과 데이터에 접근할 경로를 조직한 자료구조다. 이 절의 대표 예는 테이블과 별도로 유지하는 보조 인덱스이며, 행이 바뀌면 DBMS가 관련 인덱스도 함께 유지한다. 행의 위치뿐 아니라 질의에 필요한 열 값도 인덱스에 저장할 수 있다.

조건에서 접근경로까지

고객번호가 17이고 주문시각이 최근인 주문을 묻는 질의가 반복된다면 고객번호와 주문시각 순서의 인덱스가 후보가 된다. DBMS는 전체 행 읽기와 인덱스 탐색의 비용을 비교해 실행방법을 고른다. 선두 열, 조건의 선택도, 읽을 행의 비율과 정렬 요구가 맞아야 인덱스가 실제 이득을 낸다.

SQL 조건의 =는 같음, >=는 이상을 비교하고 AND는 두 조건을 모두 만족해야 한다는 뜻이다. 아래 예의 ...에는 실제 조회 기준시각이 들어가며 그대로 실행할 코드가 아니다. 여기서 순서는 인덱스에 저장할 열의 순서 (고객번호, 주문시각)를 말한다. WHERE 고객번호=17 AND 주문시각>=...의 조건을 문장 앞뒤로 바꾸는 것과 다르다. DBMS는 논리적으로 같은 조건을 최적화할 수 있으므로 WHERE 나열 순서 변경을 인덱스 설계로 취급하지 않는다.

인덱스가 많을수록 좋은가

인덱스는 읽기를 빠르게 할 수 있지만 저장공간을 쓰고 삽입·수정·삭제마다 갱신 비용을 낸다. 조건에 쓰이지 않거나 값 종류가 너무 적은 열의 인덱스는 선택되지 않을 수 있다. 느린 질의를 보면 인덱스를 먼저 추가하지 말고 실제 실행계획, 반환량, 복합 인덱스의 열 순서와 갱신 부하를 확인한다.

질의 문장에서 실제 데이터 접근까지

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

SQL의 구문·권한을 확인한 뒤 DBMS가 조건·통계·비용을 비교한다. 전체 읽기 또는 인덱스 탐색과 행 위치 접근을 선택해 결과를 만든다. 행 조회가 필요한 보조 인덱스의 대표 경로이며 인덱스만으로 값을 얻는 예외는 아래에서 구분한다. 두 경로는 대안이며 인덱스가 항상 더 빠른 것은 아니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

읽기계획과 별개로, 이 그림은 검사를 통과한 쓰기 경로를 보여 준다. 제약·트랜잭션 검사에서 거절되면 원본 행과 인덱스를 기록하지 않고 오류를 반환한다. 통과한 요청은 원본 행 기록과 관련 인덱스 갱신을 함께 다루고 커밋 또는 기록 중 오류 결과를 확인한다.

질의는 원하는 결과를 말하고 실행계획은 그 결과를 얻을 접근 순서를 정한다. 인덱스는 후보 경로일 뿐이며 반환할 행이 많거나 인덱스 열의 배치가 조건·정렬 요구에 맞지 않으면 전체 읽기가 더 쌀 수 있다. DBMS는 데이터와 인덱스의 통계 추정을 이용해 비용을 비교한다.

인덱스만으로 필요한 값을 얻는 경로도 있다. 질의에 필요한 열이 모두 인덱스에 있고 해당 인덱스 종류가 지원하면 인덱스 전용 스캔이 후보가 된다. 다만 PostgreSQL에서는 그 행을 현재 질의가 볼 수 있는지도 확인한다. 페이지의 가시성 정보로 이를 확인할 수 없으면 원본 행에 접근하므로, 열을 모두 포함했다고 원본 읽기 0회를 보장하지는 않는다. 아래 주문 질의도 필요한 주문번호를 인덱스에서 얻을 수 있는지 실제 계획으로 확인해야 한다.

저장 대상·관리자·질문·경로를 구분한다

SQL이 곧 DBMS는 아니며 인덱스가 원본 데이터도 아니다. 역할을 나누면 질의 문장, 실행 시스템, 접근 경로 중 어디를 개선할지 판단할 수 있다.

인덱스는 읽기 이득을 쓰기·공간 비용과 교환한다

자주 실행되고 소수 행만 반환하며 조건·정렬 순서가 맞는 질의는 인덱스 이득이 크다. 반대로 값 종류가 적고 대부분 행을 읽는 조건은 인덱스에서 원본 행을 오가는 비용이 전체 읽기보다 클 수 있다. 복합 인덱스는 선두 열과 인덱스 열 순서가 중요하며 인덱스를 추가할 때마다 삽입·수정·삭제가 관련 구조를 갱신한다. 실제 실행계획과 읽은 행 수, 수행 빈도, 쓰기 지연과 저장공간으로 유지·삭제를 결정한다.

사례: 주문 100만 건 중 고객 17의 최근 20건

전체 테이블을 읽으면 최대 100만 행을 검사한다. 고객이 10만 명이고 주문이 고르게 분포한다면 한 고객은 평균 약 10건이다. (고객번호, 주문시각) 복합 인덱스는 고객 17 범위를 찾아 최신 순서로 최대 20건만 읽는 접근경로가 될 수 있다. 반면 결제완료 여부가 95% 행에서 참이라면 그 조건만의 인덱스는 약 95만 행을 가리켜 이득이 작다. 실행계획에서 추정·실제 행 수가 크게 다르면 통계와 조건 상관관계도 확인한다.

작은 표에서 먼저 결과를 정해 보자. 자체 예의 주문은 O1(고객 17, 09:00), O2(고객 52, 09:10), O3(고객 17, 09:20), O4(고객 17, 09:30) 네 행이다.

문장을 나누어 읽으면 SELECT 주문번호는 보여 줄 열, FROM 주문은 읽을 테이블, WHERE 고객번호=17은 남길 행의 조건이다. ORDER BY 주문시각 DESC는 주문시각의 내림차순, 즉 최근 시각부터의 정렬이고 LIMIT 2는 반환할 행을 최대 두 개로 제한한다.

SELECT 주문번호 FROM 주문 WHERE 고객번호=17 ORDER BY 주문시각 DESC LIMIT 2는 “고객 17인 행을 고르고, 주문시각 내림차순으로 정렬해 최대 2개 주문번호를 반환”한다. 답은 O4, O3이다. 전체 읽기는 네 행을 검사한 뒤 고르고 정렬한다. (고객번호, 주문시각) 인덱스가 이 질의에 맞게 사용되면 고객 17 범위의 최신 쪽에서 두 행을 찾을 수 있다. 정렬 방향·동일 시각의 추가 순서키·행 접근비용에 따라 실제 계획은 달라지므로 이 작은 예의 경로를 제품 성능 보장으로 확대하지 않는다. LIMIT 20으로 바꾸면 고객 17 주문 세 건만 반환하며 빈자리를 채우지 않는다.

자체 10점 문제

DB와 DBMS, SQL 질의와 인덱스의 관계를 설명하고 인덱스 선정 및 검증방안을 제시하시오.

요구어는 설명, 제시다. DB와 DBMS를 분리 정의하고 질의 → 최적화 → 실행계획 → 데이터 접근 흐름을 그린다. 선택도·복합열 순서·정렬·빈도와 쓰기 비용을 비교하고 실제 실행계획으로 검증한다.

10점 풀이 방향과 모범답안 보기

답안 목차: 질문–계획–경로–검증

1. DB·DBMS·질의·SQL·인덱스 정의와 역할
2. SQL 해석과 비용 기반 실행계획 선택 흐름
3. 전체 읽기와 인덱스 탐색 비교
4. 선택도·복합열 순서·정렬·읽기/쓰기 교환관계
5. 실행계획·실제 행 수·빈도·갱신부하 검증과 정리

답안 도식: 인덱스 선택의 네 축

질의 조건·정렬에서 볼 축	확인할 근거
반환 비율(선택도)	실제 읽을 행의 비율
복합열 순서	선두 열·조건·정렬의 일치
실행 빈도·지연 이득	동일 부하의 측정
쓰기·공간 유지비	원본 변경의 인덱스 갱신 비용

이 네 축으로 후보 인덱스를 고르고 읽기 대안과 쓰기 경로의 실행계획·실측을 대조해 유지·변경·제거를 결정한다.

모범답안 축약본

DB는 관련 데이터를 구조와 의미에 따라 지속 저장한 집합이고 DBMS는 그 구조 정의, 저장·질의, 동시성·복구·보호를 관리하는 소프트웨어다. SQL 질의는 관계형 데이터에서 원하는 조건·결합·정렬·집계를 표현한다. DBMS는 통계와 비용으로 전체 읽기 또는 인덱스 탐색 같은 실행계획을 고른다. 인덱스는 열 값에서 행 위치로 가는 보조 자료구조라서 소수 행 조회와 정렬을 빠르게 할 수 있지만 원본 변경마다 갱신되고 공간을 쓴다. 선정은 반환 비율, 복합열의 선두 순서, 질의 빈도·정렬, 쓰기 부하로 판단한다. 느린 질의에 무조건 인덱스를 추가하지 말고 실제 실행계획, 추정과 실제 행 수, 읽기 지연과 갱신 비용을 측정해 유지·변경·제거한다.

자체 25점 문제

주문 100만 건에서 고객별 최근 주문 조회를 개선하는 인덱스 설계·검증·운영 절차를 제시하시오.

요구어는 설계, 검증, 제시다. 예상 행 수만으로 끝내지 않고 질의형태, 후보 인덱스, 실행계획, 쓰기 비용, 통계 오차와 제거 기준까지 같은 절차로 묶는다.

25점 풀이 방향과 모범답안 보기

25점 답안 목차

1. 대상 질의·지연·빈도 기준선
2. 조건·정렬·반환행 비율
3. 전체 읽기 비용
4. 복합 인덱스 후보와 열 순서
5. 읽기 이득과 쓰기·공간 비용
6. 실행계획의 추정·실제 행 수
7. 부하 조건 실측과 통계 갱신
8. 유지·변경·제거 기준

25점 답안 도식

검증 순서	비교할 것
질의 기준선	조건·정렬·빈도
후보 설계	(고객번호, 주문시각) 인덱스
실행계획 확인	추정행과 실제행
동일 부하 실측	읽기 지연과 쓰기/공간 비용
운영 결정	유지 / 통계 갱신 / 순서 변경 / 제거

앞의 접근계획 그림에서 선택된 경로와 이 표의 실측 결과를 함께 설명한다.

25점 모범답안

먼저 고객별 최근 20건 조회의 현재 지연, 실행빈도, 전체 주문 수와 쓰기 부하를 기준선으로 측정한다. 조건이 고객번호이고 정렬이 최근 주문시각이라면 (고객번호, 주문시각) 복합 인덱스를 후보로 둔다. 주문 100만 건을 전부 읽는 계획과 고객 범위를 찾아 필요한 순서로 읽는 계획의 예상 행 수와 비용을 비교한다.

실행계획에서 인덱스 사용 여부만 보지 않고 추정행과 실제행, 읽은 블록·행 수, 지연을 확인한다. 추정과 실제가 크게 다르면 통계 노후화나 조건 상관관계를 점검한다. 결제완료처럼 대부분 행이 같은 값인 단일 조건 인덱스는 반환 범위가 커 이득이 작을 수 있다.

인덱스는 원본 쓰기마다 갱신되고 저장공간을 사용하므로 동일 부하에서 읽기 지연 감소와 쓰기 지연·공간 증가를 함께 측정한다. 실제 사용빈도와 이득이 낮거나 다른 인덱스에 포괄되면 제거 후보로 두고, 질의형태가 바뀌면 열 순서와 포함 범위를 다시 검증한다.

작은 네 행 예에서 정답 O4·O3를 먼저 고정하고 인덱스 전후 결과가 같음을 확인한다. 읽기 전용 SELECT 경로와 INSERT/UPDATE가 원본·인덱스를 함께 유지하는 쓰기 경로를 분리해 시험한다. WHERE 조건의 나열만 바꾼 실험은 복합 인덱스 열 순서를 바꾼 실험으로 세지 않는다.

출처와 적용 경계

DBMS·질의·인덱스와 실행계획의 역할은 안정된 데이터베이스 기초개념이다. 주문 100만 건, 고객 10만 명, 95% 결제완료 비율은 선택도와 비용을 연습하기 위한 자체 사례이며 특정 DBMS 옵티마이저의 실제 비용식이나 성능을 뜻하지 않는다.

PostgreSQL 18의 인덱스 전용 스캔 문서를 지원 종류·필요한 열·행 가시성 조건의 근거로 참고한다. 일반 인덱스 경로와 인덱스 전용 스캔을 구분하며, 특정 제품의 조건을 모든 DBMS에 그대로 적용하지 않는다.

자기교정과 조건 변경

고객별 주문이 평균 10건에서 1만 건으로 늘어나면? 반환 범위와 정렬 비용이 달라지므로 페이지 크기·조건·인덱스 열 순서를 다시 측정한다.

쓰기 부하가 10배 늘어나면? 인덱스 유지비가 커지므로 읽기 이득과 쓰기 지연을 같은 부하에서 재평가한다.

최근 20건이 아니라 결제완료 주문만 찾는 조건이 추가되면? 결제상태의 분포와 고객번호·주문시각과의 결합 선택도를 측정한 뒤 후보 인덱스를 비교한다.

한 번에 되찾기

DBMS는 데이터 정의·저장·질의·동시성·복구·보호를 맡는다. 질의는 원하는 결과를 표현하고 인덱스는 그 결과로 가는 보조 접근경로이며, 읽기 이득과 쓰기 유지비용을 함께 판단한다.