두 열을 함께 정렬하기: Composite Index와 열 순서

About this offer

책 목록에서 과학책을 골라 가격순으로 보여 주는 화면을 만든다고 하겠습니다. DB(Database)는 자료를 저장하고 찾는 시스템입니다. 표의 한 줄은 행, 분류나 가격처럼 같은 종류의 값을 담는 항목은 열이라고 부릅니다. 앞선 Index 글 에서는 후보 행을 찾는 과정을 살펴봤습니다. Index는 원하는 행을 찾도록 돕는 보조 자료구조입니다. 이번에는 두 열을 묶었을 때 정렬 순서가 조회에 어떻게 연결되는지 확인하겠습니다. 분류를 먼저, 같은 분류에서는 가격을 Composite Index는 여러 열을 정해진 순서로 묶은 Index입니다. 여기서는 (분류, 가격) 순서를 사용합니다. 분류가 같은 항목끼리 모이고, 그 안에서 가격순으로 놓입니다. SQLite라는 DB 관리 프로그램의 여러 열 Index도 이런 순서로 값을 정렬합니다. SQLite 여러 열 Index 설명 예제의 category 는 분류, price 는 가격을 뜻합니다. 과학은 science , 역사는 history 로 저장하겠습니다. 아래 표는 Index의 정렬 순서를 설명하는 모형입니다. 실제 저장 공간의 모양과 읽은 횟수는 환경별로 따로 확인합니다. 먼저 보는 분류 같은 분류 안의 가격 history 9,000 → 12,000 → 20,000 science 10,000 → 15,000 → 18,000 과학이라는 분류를 정하면 과학 묶음에 집중할 수 있습니다. 그 안에서 12,000원 이상을 찾으면 15,000원과 18,000원이 남습니다. 두 값은 이미 가격순으로 놓여 있습니다. 열 순서를 (가격, 분류) 로 바꾸면 가격이 먼저 기준이 됩니다. 같은 가격 안에서 분류를 정리합니다. 준비된 순서가 달라지므로, 자주 찾는 조건과 필요한 정렬 순서를 함께 적고 Index를 설계해야 합니다. 작은 표에서 읽는 계획 확인하기 SQL은 DB에 작업을 요청하는 언어입니다. WHERE 는 찾을 조건, ORDER BY 는 결과의 순서를 지정합니다. SELECT 는 값을 읽고, CREATE TABLE 은 표를 만들며, INSERT 는 행을 넣습니다. CREATE INDEX 는 Index를 만듭니다. 이번 실험은 SQLite의 독립 Memory DB에서 실행했습니다. Memory는 실행 중에 자료를 담는 공간입니다. 이 공간에 새 DB를 만들어 예제만 실행했습니다. EXPLAIN QUERY PLAN 은 조회에 사용할 읽기 계획을 보여 줍니다. 먼저 Index가 없는 계획을 보고, 만든 뒤 같은 조건의 계획과 결과를 확인합니다. CREATE TABLE book ( id INTEGER PRIMARY KEY, category TEXT NOT NULL, price INTEGER NOT NULL ); INSERT INTO book VALUES (1, 'science', 18000), (2, 'history', 12000), (3, 'science', 10000), (4, 'history', 20000), (5, 'science', 15000), (6, 'history', 9000); EXPLAIN QUERY PLAN SELECT category, price FROM book WHERE category = 'science' AND price >= 12000 ORDER BY price; CREATE INDEX book_category_price_idx ON book(category, price); EXPLAIN QUERY PLAN SELECT category, price FROM book WHERE category = 'science' AND price >= 12000 ORDER BY price; SELECT category, price FROM book WHERE category = 'science' AND price >= 12000 ORDER BY price; EXPLAIN QUERY PLAN SELECT category, price FROM book WHERE price >= 12000 ORDER BY price; SELECT category, price FROM book WHERE price >= 12000 ORDER BY price; book 은 책 표의 이름이고, id 는 각 행을 구분하는 번호입니다. INTEGER 는 정수, TEXT 는 글자 값을 담습니다. PRIMARY KEY 는 행을 구분하는 기본 열로 지정하고, NOT NULL 은 값이 없음을 나타내는 NULL 의 입력을 제한합니다. AND 로 연결한 두 조건은 함께 만족해야 합니다. >= 는 기준값을 포함해 큰 값을 찾습니다. ORDER BY price 는 가격이 작은 순서로 결과를 요청합니다. 계획과 결과를 차례로 읽기 첫 계획에는 SCAN book 과 USE TEMP B-TREE FOR ORDER BY 가 나왔습니다. 표를 살펴본 뒤 결과의 가격순 정렬에 임시 구조를 사용하는 계획입니다. B-tree는 정렬된 값을 관리하는 자료구조입니다. Index를 만든 뒤에는 다음 표시가 나왔습니다. SEARCH book USING COVERING INDEX book_category_price_idx (category=? AND price>?) SEARCH 는 조건으로 범위를 좁혀 읽는 경로입니다. 괄호 안에는 분류와 가격 조건이 계획에 쓰였음을 보여 줍니다. 이 표시의 price>? 는 범위 조건의 요약입니다. 실행한 SQL의 기준은 그대로 price >= 12000 입니다. Covering Index는 조회에 필요한 열을 Index가 모두 담고 있는 경우입니다. 이번에는 분류와 가격만 읽으므로, 두 열을 담은 Index에서 결과를 얻습니다. 이 계획에는 추가 가격 정렬 표시가 없습니다. SQLite 실행 계획 표시 설명 반환된 값은 (science, 15000) , (science, 18000) 입니다. Index 생성 전후의 조회 결과도 같았습니다. 확인한 내용은 읽기 계획과 결과입니다. 처리 시간을 재는 시험은 수행하지 않았습니다. 첫 열의 조건을 빼면 무엇이 달라질까? 마지막 조회는 모든 분류에서 12,000원 이상을 찾습니다. 이 실험의 계획은 다시 SCAN book 과 임시 가격 정렬을 선택했습니다. 결과는 history 12000 → science 15000 → science 18000 → history 20000 입니다. (분류, 가격) 으로 준비된 순서에서 분류 묶음을 넘나드는 전체 가격순은 따로 맞춰야 합니다. 실제 선택은 Planner, 즉 읽는 방법을 고르는 기능이 결정합니다. 저장한 값의 분포와 수집한 통계도 판단에 쓰입니다. SQLite의 Skip-scan은 앞 열의 값 묶음을 차례로 옮기며 뒤 열 조건을 찾는 방법입니다. 앞 열에 반복 값이 많고 통계 등 조건이 맞으면 이런 경로도 선택할 수 있습니다. SQLite Skip-scan 조건 PostgreSQL도 DB 관리 프로그램입니다. PostgreSQL 18의 여러 열 B-tree Index 설명에서도 앞 열 조건과 Skip-scan을 다룹니다. 위 실행 결과는 SQLite에서 확인했습니다. PostgreSQL의 선택은 해당 환경에서 실행 계획을 확인해야 합니다. PostgreSQL 18 여러 열 Index 확인 문제 (분류, 가격) 에서 과학 묶음의 가격은 어떤 순서로 놓일까요? 과학이라는 조건을 빼면 이번 실험은 어떤 읽기 계획을 선택했을까요? Index를 만든 뒤 계획이 바뀌었다면, 실제 처리 시간은 어떻게 확인할까요? 답과 해설 과학 묶음 안에서 10,000원, 15,000원, 18,000원 순서입니다. 분류를 고정한 뒤 가격순으로 읽는 흐름과 연결됩니다. 표를 살펴보는 SCAN book 과 임시 가격 정렬을 선택했습니다. 다른 자료와 통계에서는 Planner의 선택이 달라질 수 있습니다. 같은 자료와 요청 조건에서 결과를 확인하고 시간을 따로 재야 합니다. 실행 계획은 어떤 경로를 골랐는지 알려 줍니다. 오늘은 분류와 가격 여섯 쌍을 직접 정렬하고, 과학 조건으로 남는 값을 표시해보겠습니다. 하루 뒤에는 12,000원을 16,000원으로 바꾸고 남는 값을 예상해보겠습니다. 일주일 뒤에는 자주 쓰는 조회 하나에서 조건 열과 정렬 열을 적고 Index 순서를 설명해보면 좋겠습니다. 앞선 JOIN 글 에서는 관련 행을 묶어 읽는 결과를 확인했습니다. JOIN의 결과와 이 글의 읽기 계획을 함께 떠올려보면, 원하는 결과를 정하는 일과 결과를 찾을 경로를 고르는 일을 이어서 설명할 수 있습니다. 자료 확인: 2026-10-07, SQLite 공식 문서와 PostgreSQL 18 공식 문서. 실행 환경: 프로그램을 작성하는 언어인 Python 3.12.14, SQLite 3.53.1, 독립 :memory: DB. 예제의 계획 표시와 결과를 확인했으며, 운영 환경의 성능은 별도 시험이 필요합니다.