WebMaster

Ch08. 데이터 무결성 - Check 제약 조건

webmaster — Mon, 8 Jun 2026 19:19:36 +0900

데이터의 "내용" 자체에 대한 규칙은 어떻게 적용할까?

상품의 가격(price)이나 재고 수량(stock_quantity)은 절대 음수일 수 없다.
할인율(discount_rate)은 "0%"에서 "100%" 사이의 값이어야 한다.

`NOT NULL` 제약 조건은 가격에 `-5000` 이라는 값이 들어오는 것을 막지 못한다. "UNIQUE" 제약 조건은 할인율이 "200"이 되는 것을 막지 못한다. 이런 값들은 형식적으로는 유효하지만, 비즈니스 논리상으로는 명백한 "쓰레기 데이터"다.

이처럼 특정 컬럼에 들어갈 수 있는 값의 범위나 조건을 직접 지정하여, 한층 더 강화된 비즈니스 규칙을 적용하고 싶을때 사용하는 것이 바로 CHECK 제약 조건이다.

CHECK 제약 조건의 역할과 문법

"CHECK" 제약 조건은 특정 컬럼에 대해, "INSERT" 또는 "UPDATE"가 일어날 때마다 지정된 조건식이 "참(true)"인지를 검사한다. 만약 조건식이 "거짓(false)"이면, 데이터베이스는 해당 데이터의 입력을 거부하고 에러를 발생시킨다. 문법은 테이블을 생성할 때 컬럼 정의 뒤에 "CHECK (조건식)"을 추가해 주면 된다.

-- 실습을 위해 기존 테이블들을 삭제한다.
DROP TABLE IF EXISTS orders;
DROP TABLE IF EXISTS products;
-- CHECK 제약 조건을 추가하여 products 테이블 재생성
CREATE TABLE products (
	product_id BIGINT AUTO_INCREMENT PRIMARY KEY,
	name VARCHAR(255) NOT NULL,
	category VARCHAR(100),
	price INT NOT NULL CHECK (price >= 0),
	stock_quantity INT NOT NULL CHECK (stock_quantity >= 0),
	discount_rate DECIMAL(5, 2) DEFAULT 0.00 CHECK (discount_rate BETWEEN 0.00 AND 100.00)
);

"price >= 0": 가격은 "0" 이상이어야 한다.
"stock_quantity >= 0" : 재고 수량은 "0" 이상이어야 한다.
"discount_rate BETWEEN 0.00 AND 100.00" : 할인율은 "0"과 "100" 사이의 값이어야 한다.
- "(discount_rate >= 0 AND discount_rate <= 100)"과 동일

참고로 제약 조건에 이름을 부여하려면 DDL에서 다음과 같은 SQL을 작성하면 된다.

CONSTRAINT products_chk_price CHECK (price >= 0)

가격에 음수 입력 시도

insert into products (name, category, price, stock_quantity) 
values('오류상품', '전자기기', -5000, 10);

Error Code: 3819. Check constraint 'products_chk_1' is violated.
데이터베이스가 "products_chk_1"이라는 이름의 "CHECK 제약 조건"(가격은 0 이상)이 위반되었다며, 데이터 입력을 단호하게 거부했다.

할인율에 범위를 벗어난 값 입력 시도

insert into products (name, category, price, stock_quantity, discount_rate)
values('오류상품', '전자기기', -5000, 10, 120.00);

Error Code: 3819. Check constraint 'products_chk_1' is violated.
할인율의 범위를 검사하는 "CHECK 제약 조건"이 "문지기" 역할을 훌륭하게 수행했다.

이처럼 "CHECK 제약 조건"은 애플리케이션 레벨에서 놓칠 수 있는 데이터의 유효성 검사를 데이터베이스가 직접 수행하여, 비즈니스 규칙에 어긋나는 데이터가 저장될 가능성을 원천적으로 차단하는 강력한 수단이다.

데이터 검증, 어디서 하는 게 좋을까?

요즘 대세는 애플리케이션 코드: 대부분의 비즈니스 로직과 유효성 검사는 애플리케이션에서 직접 처리한다. 훨씬 유연하고 테스트가 쉽기 때문이다.

DB "CHECK 제약 조건"은 신중하게: 이런 이유로 데이터베이스의 CHECK 제약 조건은 잘 사용하지 않는 추세이다.

최후의 방어선으로 활용: CHECK 제약 조건을 쓴다면, 간단하지만 절대 값이 바뀌면 안 되는 핵심 데이터에만 최후의 방어선으로 사용하는 것이 좋다.

Ch08. 데이터 무결성 - 외래 키 제약 조건

webmaster — Mon, 8 Jun 2026 19:19:21 +0900

참조 무결성이란, 두 테이블의 관계가 항상 유효하고 일관된 상태를 유지해야 한다는 원칙이다.

예를 들어, orders 테이블의 user_id 컬럼은 반드시 users 테이블에 실제로 존재하는 "user_id" 값만을 참조해야 한다. 만약 존재하지도 않는 유령 회원의 주문이 있다면, 이 관계는 깨진 것이다. 이러한 테이블 간의 관계 무결성을 강제하는 가장 강력한 제약 조건이 바로 외래 키(Foreign Key)다.

외래 키(FK)의 역할: 유령 데이터를 막아라

자식 테이블(orders)에 INSERT, UPDATE 할 때: 부모 테이블(users)에 존재하지 않는 "user_id" 값을 자식 테이블(orders)의 "user_id" 컬럼에 넣으려는 시도를 막는다. (유령 주문 생성 방지)
부모 테이블(users)에서 DELETE, UPDATE 할 때: 자식 테이블(orders)에서 참조하고 있는 "user_id" 값을 가진 행을 함부로 삭제하거나 변경하지 못하게 막는다. (기존 주문을 유령 주문으로 만드는 것 방지)

유령 주문 생성 시도

"존재하지 않는 user_id인 999번 고객의 주문을 넣어보자."

insert into orders(user_id, product_id, quantity)  values(999, 1, 1);

Error Code: 1452. Cannot add or update a child row: a foreign key constraint fails (`my_shop2`.`orders`, CONSTRAINT `fk_orders_users` FOREIGN KEY (`user_id`) REFERENCES `users` (`user_id`))
데이터베이스는 "fk_orders_users" 외래 키 제약 조건이 실패했다는 명확한 에러를 출력하며, 이 INSERT를 거부했다.

주문이 있는 고객 삭제 시도

"'션' 고객(user_id =1)은 이미 주문 기록이 있다."

delete from users where user_id = 1;

Error Code: 1451. Cannot delete or update a parent row: a foreign key constraint fails (`my_shop2`.`orders`, CONSTRAINT `fk_orders_users` FOREIGN KEY (`user_id`) REFERENCES `users` (`user_id`))
데이터베이스는 이 고객을 참조하는 주문이 있기 때문에 삭제할 수 없다는 오류를 발생시키며 삭제를 막는다
- 만약 이 삭제 쿼리가 성공한다면 orders 테이블에는 "션" 고객(user_id =1)의 주문이 남아있지만, users 테이블의 "션"은 제거된다.
- 결과적으로 주문 내역만 있고, 실제 고객은 사라지는 심각한 문제가 발생한다. 그리고 향후 이 주문이 누구의 주문인지 찾을 수 없게 된다.
만약 부모 테이블의 션(user_id = 1) 데이터를 삭제하고 싶다면 다음과 같이 자식 테이블의 "션" 관련 데이터를 먼저 삭제하고, 이후에 부모 테이블을 삭제하는 순서로 진행해야 한다.

ON DELETE / ON UPDATE 옵션

데이터베이스가 부모 데이터의 삭제나 수정을 무조건 막는 것이 기본값(RESTRICT)이며 가장 안전한 정책이다. 하지만 때로는 비즈니스 규칙에 따라 다른 정책이 필요할 수 있다. 예를 들어 "회원이 탈퇴하면, 그 회원의 모든 주문 기록도 함께 삭제되어야 한다" 와 같은 경우다.

이럴 때 사용하는 것이 외래 키의 "ON DELETE"와 "ON UPDATE" 옵션이다.

RESTRICT (기본값): 자식 테이블에 참조하는 행이 있으면 부모 테이블의 행을 삭제/수정할 수 없다. (방금 확인한 동작)
CASCADE: 부모 테이블의 행이 삭제/수정되면, 그를 참조하는 자식 테이블의 행도 함께 자동으로 삭제/수정된다.
SET NULL: 부모 테이블의 행이 삭제/수정되면, 자식 테이블의 해당 외래 키 컬럼의 값을 "NULL"
- 단, 이 옵션을 쓰려면 자식 테이블의 외래 키 컬럼이 "NULL"을 허용해야 한다.

-- 실습을 위해 기존 테이블 삭제 후 CASCADE 옵션으로 재생성
DROP TABLE orders;
CREATE TABLE orders (
	order_id BIGINT AUTO_INCREMENT,
	user_id BIGINT NOT NULL,
	product_id BIGINT NOT NULL,
	order_date DATETIME DEFAULT CURRENT_TIMESTAMP,
	quantity INT NOT NULL,
	status VARCHAR(50) DEFAULT 'PENDING',
	PRIMARY KEY (order_id),
	CONSTRAINT fk_orders_users FOREIGN KEY (user_id)
	REFERENCES users(user_id) ON DELETE CASCADE, -- CASCADE 옵션 추가
	CONSTRAINT fk_orders_products FOREIGN KEY (product_id)
	REFERENCES products(product_id)
);
-- 션 회원 다시 등록
INSERT INTO users(user_id, name, email, address, birth_date) VALUES (1,'션', 'sean@example.com','서울시 강남구', '1990-01-15');
-- 주문 데이터 다시 입력
INSERT INTO orders(user_id, product_id, quantity, status) VALUES (1, 1, 1, 'COMPLETED'),(1, 4, 2, 'COMPLETED'),(2, 2, 1, 'SHIPPED');

회원 데이터("션")

select * from users where user_id = 1;

쿼리 결과

"션" 고객이 생성되었다.

주문 데이터("션")

select * from orders where user_id = 1;

쿼리 결과

"션"(user_id = 1)이 주문한 주문이 2건이 존재한다.(order_id = 4, 5)

"션" 고객 삭제

delete from users where user_id = 1;

아무 에러 없이 쿼리가 성공적으로 실행된다.
"션"(user_id = 1)인 고객의 주문 내역이 모두 연쇄적으로 함께 삭제된 것을 확인할 수 있다(order_id = 4, 5 제거)

CASCADE 옵션은 매우 편리하지만, 의도치 않은 대량의 데이터 삭제를 유발할 수 있으므로 반드시 비즈니스 로직을 명확히 이해하고 신중에 신중을 기해서 사용해야 한다

CASCADE - 실무 이야기

CASCADE 옵션은 분명 편리한 기능이지만, 잘못 사용할 경우 예상치 못한 대량의 데이터가 함께 삭제되는 경우가 있다. 특히 관계가 복잡하게 얽혀 있는 경우에는 파급 효과를 예측하기 어렵다. 이런 문제로 실무에서는 CASCADE 옵션은 잘 사용하지 않는다. 대신에 애플리케이션 계층에서 명시적으로 관련된 데이터를 처리하는 방식이 더 선호된다.

외래 키는 테이블 간의 관계를 정의하는 것을 넘어, 그 관계가 항상 올바른 상태를 유지하도록 강제하는 데이터베이스의 핵심적인 무결성 장치다.

Ch08. 데이터 무결성 - 기본 키 제약 조건

webmaster — Mon, 8 Jun 2026 19:19:08 +0900

NOT NULL: NULL 값 방지

역할: 해당 컬럼에 NULL 값(값이 없는 상태)이 저장되는 것을 허용하지 않는다.
- 반드시 필요한 정보가 누락되는 것을 막는다.
문법 예시: "email VARCHAR(255) NOT NULL"

"회원 가입 시 필수 정보인 이메일을 실수로 "NULL"로 입력하려고 시도해 보자.

insert into users(name, email) values('냐옹이', null);

insert into users(name, email) values('냐옹이', null) Error Code: 1048. Column 'email' cannot be null 0.00076 sec
데이터베이스는 email 컬럼은 NULL일 수 없다는 명확한 에러 메시지를 반환하며, 이 INSERT 명령을 거부한다.

UNIQUE : 중복 값 방지

역할: 해당 컬럼에 들어가는 모든 값은 테이블 내에서 반드시 고유해야(unique) 한다. 중복 데이터가 쌓이는 것을 막는다.
문법 예시: "email VARCHAR(255) UNIQUE"

"이미 가입된 이메일 주소(sean@example.com)로 다른 사람이 또 가입을 시도하는 상황이다.

insert into users(name, email, address) values ('가짜 션', 'sean@example.com', '서울시 어딘가');

Error Code: 1062. Duplicate entry "sean@example.com" for key "users.email"
데이터베이스는 "sean@example.com"이라는 값이 "users.email" 키에 대해 중복되었다는 에러와 함께 "INSERT"를 거부한다.

PRIMARY KEY (기본 키): 행의 대표 식별자

역할: 테이블의 각 행을 고유하게 식별할 수 있는 단 하나의 대표 키. "NOT NULL"과 "UNIQUE" 제약 조건의 특징을 모두 포함한다.
- 즉, 기본 키 컬럼은 절대 "NULL" 일 수 없으며, 절대 중복될 수 없다.
특징: 테이블당 오직 하나만 설정할 수 있으며, 이 기본 키를 기준으로 데이터가 저장되고 검색되므로 성능에도 매우 중요한 역할을 한다.
- MySQL은 기본 키에 자동으로 고성능 인덱스를 생성한다.
문법 예시: "user_id BIGINT PRIMARY KEY"

이미 존재하는 "user_id" "1번"으로 새로운 데이터를 삽입하려고 하거나, "id"를 "NULL"로 삽입하려고 시도해 보자.

insert into users(user_id, name, email) values(1, '누군가','someone@example.com');

Error Code: 1062. Duplicate entry '1' for key 'users.PRIMARY'
users 테이블의 "user_id"를 "AUTO_INCREMENT"를 사용했기 때문에 자동 증가하는 값이기에 "NULL"을 입력해도 값이 자동으로 입력된다.
- 만약 "AUTO_INCREMENT"가 아니라면 PK에 NULL을 입력하면 오류가 발생한다

DEFAULT : 기본값 설정

역할: 특정 컬럼에 값을 명시적으로 입력하지 않았을 경우, 자동으로 설정될 기본값을 지정한다.
- 엄밀히 말해 무결성을 "강제"하는 규칙이라기보다는, 데이터 누락을 방지하고 입력을 편리하게 해주는 기능에 가깝다.
문법 예시: "status VARCHAR(50) DEFAULT 'PENDING'"

"orders" 테이블에 주문을 추가할 때, 주문 상태(status)를 따로 지정하지 않으면 기본값인 "PENDING"으로 자동 설정된다.

insert into orders (user_id, product_id, quantity) values(2, 2, 1);
select * from orders order by order_id desc limit 1;

쿼리 결과

status 컬럼에 우리가 지정한 기본값인 "PENDING"이 자동으로 들어간 것을 확인할 수 있다.

Ch08. 데이터 무결성 - 데이터 무결성이 중요한 이유

webmaster — Sun, 7 Jun 2026 19:40:14 +0900

데이터 무결성이 중요한 이유

어느 날, 당신이 쇼핑몰의 월별 매출 보고서를 뽑았는데, 총매출액이 마이너스(-)로 나왔다고 상상해 보자. 황급히 원본 데이터를 살펴보니, 누군가의 실수 혹은 프로그램 버그로 인해 상품의 가격(price)에 "음수 값"이 들어가 있거나, 주문 수량(quantity)에 "-1"이 입력된 것을 발견했다. 또 다른 예로, 분명히 우리 쇼핑몰의 전체 고객은 "5명"인데, orders 테이블에는 존재하지도 않는 "user_id = 99번" 고

객의 주문 기록이 남아있다.

이런 말도 안 되는 데이터, 현실 세계에서는 결코 존재할 수 없는 데이터를 우리는 "쓰레기 데이터(Garbage Data)"라고 부른다.

쓰레기 데이터가 초래하는 재앙

잘못된 비즈니스 결정: 매출액이 음수로 찍힌 보고서를 믿고 다음 달 사업 계획을 세울 수는 없다.
치명적인 시스템 오류: 애플리케이션 코드는 상품 가격이 항상 양수일 것이라고 가정하고 만들어졌는데, 음수 가격을 마주치는 순간 예외를 발생시키며 멈춰버릴 수 있다.
데이터 불일치: users 테이블에서는 탈퇴한 고객을 삭제했는데, orders 테이블에는 그 고객의 주문 기록이 그대로 남아 "주인 없는 주문"이라는 유령 데이터가 되어 떠돌아다닌다.

그렇다면 이 쓰레기 데이터가 애초에 데이터베이스에 저장되지 못하도록 막을 책임은 누구에게 있을까? 물론 데이터를 입력하는 애플리케이션(웹사이트, 앱 등)에서 1차적으로 검증해야 한다. 하지만 그것만으로는 충분하지 않다.

애플리케이션에 미처 발견하지 못한 버그가 있을 수 있다.
여러 다른 종류의 애플리케이션이 하나의 데이터베이스에 접근할 수도 있다.
개발자나 관리자가 데이터베이스에 직접 접속해서 데이터를 수정할 수도 있다.

따라서 우리는 데이터베이스를 데이터를 지키는 최후의 보루로 만들어야 한다. 어떤 경로로 데이터 변경 요청이 들어오든, 데이터베이스 스스로가 말도 안 되는 값은 거부하고 데이터의 정확성과 일관성을 지킬 수 있도록 규칙을 설정해야 한다.

이렇게 데이터의 정확성, 일관성, 유효성을 유지하려는 성질을 데이터 무결성(Data Integrity)이라고 부른다.

그리고 이 데이터 무결성을 강제하기 위해, 테이블의 특정 컬럼에 설정하는 규칙이 바로 제약 조건(Constraints)이다.

제약 조건(Constraints)의 역할

제약 조건은 테이블에 데이터를 INSERT, UPDATE, DELETE 할 때, "이 규칙을 어기면 절대 안 돼!" 라고 외치는 문지기와 같다.

price 컬럼에는 "0" 이상의 값만 받도록 규칙을 정하고, 음수 값을 넣으려는 시도는 거부한다.
email 컬럼에는 중복된 값이 들어올 수 없도록 규칙을 정하고, 이미 가입된 이메일은 거부한다.
orders 테이블의 "user_id"는 반드시 users 테이블에 존재하는 "user_id" 값만 받도록 규칙을 정하고, 유령 회원의 주문은 거부한다.

제약 조건을 잘 설정해 둔 데이터베이스는 애플리케이션의 버그나 사용자의 실수로부터 데이터를 지켜내는 튼튼한 성벽이 된다.

Ch07. 인덱스 - 복합 인덱스 정리

webmaster — Sun, 7 Jun 2026 18:47:33 +0900

복합 인덱스 대원칙

인덱스는 순서대로 사용하라! (왼쪽 접두어 규칙)
등호(=) 조건은 앞으로, 범위 조건(<, >)은 뒤로!
정렬(ORDER BY)도 인덱스 순서를 따르라!

인덱스는 순서대로 사용하라!

이는 "인덱스 왼쪽 접두어 규칙"을 의미한다. 복합 인덱스는 "(A, B, C)" 순서로 생성되었을 때, "WHERE" 절에서 A 조건 없이는 B나 C를 사용할 수 없다. 전화번호부에서 "성"을 모르고 "이름"만으로 사람을 찾을 수 없는 것과 같은 이치다.

가능 (O): "WHERE A", "WHERE A AND B", "WHERE A AND B AND C"
불가능 (X): "WHERE B", "WHERE C", "WHERE B AND C"

이것이 복합 인덱스의 가장 기본적이고 절대적인 규칙이다.

등호(=) 조건은 앞으로, 범위 조건(<, >)은 뒤로!

복합 인덱스의 컬럼 중 하나에 범위 조건(>, <, BETWEEN, LIKE%...)이 사용되는 순간, 그 뒤에 오는 컬럼은 인덱스의 정렬 효과를 누릴 수 없다. 예를 들어, "(category, price)" 인덱스가 있을 때 "WHERE category > '도서' AND price = 30000" 쿼리를 생각해보자.

데이터베이스는 category가 "도서"보다 큰 ('생활용품', '전자기기', ...) 섹션을 인덱스에서 찾는다. 하지만 "생활용품" 섹션과 "전자기기" 섹션의 price는 서로 연결되어 정렬된 것이 아니다. 결국 데이터베이스는 "도서" 이후의 모든 인덱스를 스캔하면서, price가 "30000"인지 일일이 확인해야 한다. price 컬럼은 필터링에만 사용될 뿐, 탐색(seek)에는 사용되지 못한다.

따라서 가장 효율적인 인덱스 설계는 다음과 같은 순서를 따른다.

변별력이 높은 등호(=) 조건으로 사용할 컬럼을 인덱스 앞쪽에 배치한다.
- IN 절도 여러 개의 등호 조건으로 취급되어 유리하다.
범위 조건으로 사용할 컬럼은 인덱스 뒤쪽에 배치한다.

이렇게 하면 등호 조건으로 검색 대상을 최대한 좁힌 뒤, 그 좁은 범위 내에서만 범위 검색을 수행하므로 성능이 극대화된다.

정렬(ORDER BY)도 인덱스 순서를 따르라!

복합 인덱스의 가장 강력한 기능 중 하나는 불필요한 정렬 작업을 생략하게 해주는 것이다. "ORDER BY" 절이 인덱스 컬럼 순서와 일치하면, 데이터베이스는 이미 정렬된 인덱스를 순서대로 읽기만 하면 되므로 매우 빠르다. 이 경우 실행 계획에서 "Using filesort"가 사라지는 것을 볼 수 있다.

인덱스: (category, price)
빠른 쿼리: "WHERE category = '전자기기' ORDER BY price"
- '전자기기' 섹션은 이미 price 순으로 정렬되어 있으므로 추가 정렬이 필요 없다.
느린 쿼리 (filesort 발생): "WHERE category = '전자기기' ORDER BY stock_quantity"
- 인덱스는 "stock_quantity" 순서와는 무관하므로, 결과를 가져온 뒤 별도로 정렬해야 한다.

"WHERE" 절에서 인덱스를 잘 활용하는 것만큼, "ORDER BY"에서 "filesort"를 피하는 것도 전체 쿼리 성능에 결정적인 영향을 미친다.

결론적으로, 복합 인덱스는 단순히 여러 컬럼을 묶는 것이 아니라, "순서"와 "조건의 종류(등호/범위)"를 고려한 전략적인 설계가 핵심이다. 이 세 가지 대원칙만 명심한다면, 여러분도 실무에서 고성능 쿼리를 충분히 잘 작성할 수 있을 것이다.

Ch07. 인덱스 - 복합 인덱스(3)

webmaster — Sun, 7 Jun 2026 12:26:31 +0900

범위 검색은 마지막에 한 번만 사용!

이러한 제약 때문에 복합 인덱스를 설계할 때는 다음과 같은 순서를 따르는 것이 매우 중요하다. 등호(=) 조건을 사용하는 컬럼을 앞에, 범위 조건을 사용하는 컬럼을 뒤에 둔다.

예를 들어 아래의 쿼리가 자주 사용된다면?

select * from items where category >= '패션' and price = 20000;

최적의 인덱스는 순서를 변경해서 (price, category) 순서를 사용해야 한다.
왜냐하면 "price = 20000"이라는 등호(=) 조건을 먼저 처리해서 검색 대상을 크게 줄일 수 있기 때문이다.

(price, category) 순서의 인덱스를 추가하자

create index idx_items_price_category_temp on items(price, category);

임시로 사용할 예정이라 temp를 붙여두었다.

explain select * from items where category >= '패션' and price = 20000;

쿼리 결과

옵티마이저는 "idx_items_category_price", "idx_items_price_category_temp" 두 인덱스 중에 "idx_items_price_category_temp"가 더 효율적이라고 판단한다.
Extra(Using index condition), rows(1), filtered(100.00)을 통해 인덱스를 통해 하나의 데이터를 찾았고 해당 데이터가 별도의 필터링 없이 바로 선택된 것을 확인할 수 있다.

idx_items_price_category_temp 인덱스

idx_items_price_category_temp 인덱스

인덱스에서 price가 "20000"인 데이터 블록을 매우 빠르게 찾는다(lookup). 이는 인덱스가 "price"로 정렬되어 있기 때문에 가능한, 가장 효율적인 "ref" 방식(=)의 접근이다.
그렇게 찾아낸 좁은 데이터 집합 안에서 "category >= '패션'"이라는 범위 조건을 만족하는 데이터를 찾는다.
- 여기서는 '패선', '헬스/뷰티'를 만족하면 된다.
- price가 "20000"인 데이터들은 이미 "category" 순으로 정렬되어 있으므로, 이 과정 역시 효율적인 "range"스캔으로 처리된다.

이처럼 가장 변별력 있는 등호(=) 조건을 먼저 처리해서 작업 범위를 최대한 좁히고, 그 다음에 범위 조건을 처리하는 것이 인덱스 설계의 핵심이다. 만약 순서를 반대로 (category, price)로 했다면, "category >= '패션'"이라는 범위 검색이 먼저 수행되면서인덱스의 효율이 떨어졌을 것이다. 결론적으로, 복합 인덱스를 설계할 때는 어떤 쿼리가 주로 사용될지 예측하고, 해당 쿼리의 "WHERE" 절에 맞게 "등호 조

건 컬럼 범위 조건 컬럼" 순서로 구성하는 것이 성능 최적화의 지름길이다.

기존 인덱스를 잘 활용하자

그런데 이처럼 인덱스를 계속 만드는 것 만이 능사는 아니다. 인덱스를 추가하면 그 만큼 관리 비용이 들어간다. 기본적으로 기존에 있는 인덱스를 최대한 잘 활용하고, 그래도 안되면 인덱스 추가를 고려해야 한다.

사실 이번에 생성한 "idx_items_price_category_temp" 인덱스 없이, 기존에 만든 "idx_items_category_price" 인덱스로도 최적의 성능을 활용할 수 있는 방법이 있다.

실무 팁: IN절 활용하기

범위 조건 때문에 두 번째 인덱스 컬럼을 활용하지 못하는 이 문제는, ">" 나 "<" 같은 범위 대신 "IN" 절을 사용함으로써 해결할 수 있는 경우가 많다.

MySQL 옵티마이저는 "IN (...)"을 하나의 큰 범위로 취급하지 않고, 여러 개의 동등 비교(=) 조건의 묶음으로 인식하기 때문이다. "category >= '패션', '헬스/뷰티')"와 논리적으로 동일하다. 이 쿼리를 "IN"을 사용하도록 변경하고 실행 계획을 다시 확인해보자.

explain select * from items
where category in ('패션', '헬스/뷰티') and price = 20000;

쿼리 결과

예상 "rows"가 "6" -> "2"로 줄어들었다. 인덱스로 찾는 범위가 더 줄어든다는 뜻이다.
가장 극적인 변화는 "filtered" 컬럼이 "10.00%"에서 "100.00%"로 바뀐 것이다.
- 이것은 인덱스만을 잘 활용해서 원하는 데이터를 "100%" 다 찾았다는 의미다.
- 그래서 인덱스를 통해 찾은 데이터를 "100%" 다 통과시킨다는 의미이다.

쿼리 동작 과정

옵티마이저는 "WHERE category IN ('패션', '헬스/뷰티')"를 "WHERE category = '패션' OR category = '헬스/뷰티'" 와 동일하게 인식한다.
따라서 전체 쿼리는 내부적으로 "(category = '패션' AND price = 20000)" 또는 "(category = '헬스/뷰티' AND price = 20000)"를 만족하는 데이터를 찾는 것으로 해석된다.
"idx_items_category_price" 인덱스를 사용해 "('패션', 20000)" 조합을 만족하는 데이터를 찾는다. (첫 번째 동등 비교)
이어서 "('헬스/뷰티', 20000)" 조합을 만족하는 데이터를 찾는다. (두 번째 동등 비교)

이렇게 작성한 "IN" 쿼리는 쉽게 비유하자면 다음과 같이 나누어 실행된다.

SELECT * FROM items WHERE category = '패션' AND price = 20000;
UNION ALL
SELECT * FROM items WHERE category = '헬스/뷰티' AND price = 20000;

category = '패션'만 보면 "price"가 완전히 정렬되어 있다.
- 따라서 price 컬럼도 인덱스를 사용해서 원하는 데이터를 빠르게 찾을 수 있다.
category = '헬스/뷰티'만 보면 price가 완전히 정렬되어 있다.
- 따라서 price 컬럼도 인덱스를 사용해서 원하는 데이터를 빠르게 찾을 수 있다.

핵심은 **범위 검색이 동등 비교(=)의 여러 묶음으로 바뀌었다는 점이다. ">=" 같은 범위 조건에서는 인덱스의 두 번째 컬럼(price)을 제대로 활용할 수 없었지만, category와 price가 모두 특정 값으로 고정된 동등 비교에서는 복합 인덱스의 모든 컬럼을 효율적으로 사용할 수 있다. 즉, 옵티마이저는 "idx_items_category_price" 인덱스를 사용해 "('패션', 20000)" 지점으로 한 번, "('헬스/뷰티', 20000)" 지점으로 또 한 번, 총 두 번의 정확한 위치 탐색(seek)을 수행한다. 이 탐색 과정에서 price 조건까지 완벽하게 반영되므로, 불필요하게 데이터를 읽고 버리는 과정이 사라진다. 이것이 바로 "filtered" 컬럼이 "100.00%"로 표시되는 이유다.

결론적으로 ">"는 "연속된 범위"로 처리되어 복합 인덱스의 추가적인 활용을 막는 반면, "IN" 은 "여러 개의 개별 지점"에 대한 동등(=) 비교의 묶음으로 처리된다. 옵티마이저는 "IN" 절의 각 값에 대해 인덱스를 사용한 효율적인 탐색(Seek)을 여러 번 수행할 수 있으므로, 복합 인덱스의 모든 컬럼을 효과적으로 활용할 수 있다.

논리적으로 같은 결과를 반환하더라도, ">"는 인덱스 스캔(Scan) 방식으로 동작하여 후속 컬럼 활용에 제한이 있는 반면, "IN"은 여러 번의 탐색(Seek) 방식으로 동작하여 복합 인덱스의 모든 컬럼을 효율적으로 활용할 수 있기 때문에 성능 차이가 발생한다. 물론 "IN" 절에 들어가는 값이 수백, 수천 개로 너무 많아지면 성능이 저하될 수 있지만, 이처럼 범위 조건을 몇 개의 동등 조건으로 바꿀 수 있는 상황이라면 "IN" 절은 매우 강력한 최적화 도구가 될 수 있다.

실무에서는 범위가 한정적인 컬럼에 이 "IN" 트릭을 자주 사용한다.

예를 들어, 상품 상태를 나타내는 status 컬럼이 '판매중', '품절', '판매중지' 3가지 값만 가진다고 하자. '판매중' 또는 '품절' 상태인 상품을 찾을 때 "WHERE status >= '판매중'"과 같이 조회하는 것보다 "WHERE status IN ('판매중', '품절')"로 조회하는 것이 복합 인덱스를 활용하는 데 훨씬 유리할 수 있다.

물론, "IN" 절에 들어가는 값의 개수가 너무 많아지면 오히려 성능이 저하될 수도 있으므로, 항상 "EXPLAIN"을 통해 실제 실행 계획을 확인하고 결정하는 것이 현명하다.

Ch07. 인덱스 - 복합 인덱스(2)

webmaster — Sun, 7 Jun 2026 12:26:01 +0900

복합 인덱스 실패 예제1: 인덱스 순서 무시

"카테고리와 상관없이 가격이 80,000원인 상품을 찾아보자."

EXPLAIN SELECT * FROM items WHERE price = 80000;

쿼리 결과

type(ALL): 풀 테이블 스캔이 발생했다.
key(NULL): "idx_items_category_price" 인덱스가 있음에도 불구하고, 옵티마이저는 이 인덱스를 사용하지 않았다.

왜 이런 결과가 나왔을까? 인덱스 왼쪽 접두어 규칙 때문이다. "idx_items_category_price" 인덱스는 category로 먼저 정렬되어 있다. price가 "80000"인 상품은 '전자기기' 카테고리에도 있을 수 있고, 만약 있다면 '패션' 카테고리에도 있을 수 있다. 즉, "price" 값은 인덱스 전체에 흩어져 있다.

쿼리 동작 과정

데이터베이스 입장에서 price만으로 데이터를 찾으려면, '도서' 카테고리 섹션을 처음부터 끝까지 다 보고, '생활용품' 섹션도 다 보고, '전자기기', '패션' 등 모든 카테고리 섹션을 다 뒤져봐야 한다.
이는 인덱스 전체를 스캔하는 작업으로, 차라리 원본 테이블 전체를 스캔하는 것보다 나을 것이 없다.

복합 인덱스 실패 예제2: 범위 조건을 먼저 사용

복합 인덱스 활용에는 한 가지 더 중요한 제약 조건이 있다. 바로 선행 컬럼에 범위 조건( >, < , BETWEEN, LIKE %) 이 사용되면, 그 뒤에 오는 컬럼은 인덱스를 제대로 활용할 수 없다는 점이다.

"카테고리명이 '패션' 이상인 상품들 중에서, 가격이 정확히 20,000원인 상품을 찾아줘." 라는 요구사항을 생각해보자.

쿼리 결과

실행 계획을 자세히 분석해 보자. type이 range이고, key에 "idx_items_category_price"가 사용되었으니 언뜻 보기에는 인덱스를 잘 사용한 것처럼 보인다.
하지만 여기서 주목해야 할 것은 "filtered" 컬럼의 값인 "10.00%"와 "Extra" 컬럼의 "Using index condition"이다.

쿼리 동작 과정

"idx_items_category_price" 인덱스를 사용해 category가 '패션'인 위치를 찾는다. (>= 조건의 시작점)
거기서부터 인덱스의 끝까지 모든 데이터를 스캔한다. ('패션', '헬스/뷰티' 카테고리에 해당하는 모든 데이터)
스캔하는 각 레코드마다 "price = 20000" 조건을 만족하는지 하나하나 검사한다. (인덱스 사용이 아니라 직접 필터링한다.)

이것이 바로 "filtered: 10.00%"의 의미다. 옵티마이저는 "category >= '패션'" 조건으로 약 6개의 행을 찾을 것으로 예상하고(rows: 6 ), 그 중에서 "price = 20000" 조건을 만족하는 데이터는 10% 정도일 것이라고 예측한다. 즉, price 컬럼은 데이터를 효율적으로 "찾는(seek)" 데 사용된 것이 아니라, 일단 category 조건으로 넓게 가져온 데이터를 걸러내는(filter)데만 사용된 것이다

데이터베이스는 "category >= '패션" 조건에 따라 인덱스에서 '패션'과 '헬스/뷰티' 섹션을 찾았다. 하지만 그다음 조건인 "price = 20000"을 처리할 때 문제가 생긴다. '패션' 섹션은 "price" 순으로 정렬되어 있다. '헬스/뷰티' 섹션도 "price" 순으로 정렬되어 있다. 하지만 '패션' 섹션의 가격들과 '헬스/뷰티' 섹션의 가격들이 전체적으로 정렬된 것은 아니다. '패션'의 마지막 상품 가격이 "헬스/뷰티"의 첫 상품 가격보다 높을 수 있다.

패션 + 헬스/뷰티의 price

패션 + 헬스/뷰티의 price + item_id

합쳐진 가격은 이제 정렬된 상태가 아니다!(인덱스를 활용하려면 정렬된 상태여야 한다!)
따라서 데이터베이스는 "category >= '패션'" 범위를 스캔하면서 가져온 각각의 데이터에 대해 "price = 20000"인지 일일이 확인하는 추가 작업을 해야만 한다.
- 이렇게 찾은 패션 + 헬스/뷰티의 "price" 컬럼은 정렬되어 있지 않다!
- 따라서 인덱스를 통한 빠른 탐색이 어렵다.
데이터베이스는 "category >= '패션'" 범위를 인덱스의 category 컬럼를 통해 스캔하면서 6개의 행을 빠르게 찾았다.
하지만 가져온 각각의 데이터에 대해 "price = 20000"인지 일일이 확인하는 필터링 추가 작업을 해야만 한다.
이처럼 복합 인덱스에서 앞선 컬럼(category)에 범위 조건(>=)이 걸리는 순간, 데이터베이스는 더 이상 뒤따라오는 컬럼(price)의 정렬 순서를 활용할 수 없게 된다.
- category가 '패션'일 때의 price 정렬과 category가 '헬스/뷰티'일 때의 price 정렬은 둘을 합치는 순간 정렬이 깨지기 때문이다.
- 따라서 데이터베이스는 "category >= '패션'"이라는 범위 조건만 사용해서 인덱스를 스캔하고, 나머지 "price = 20000" 조건은 빠르게 찾지 못하고, 필터링만 수행하는 것이다.
- 이는 인덱스의 성능을 절반만 활용하는 셈이다.

이처럼 복합 인덱스에서 어떤 컬럼에 범위 검색을 사용하는 순간, 그 뒤에 오는 컬럼들은 인덱스의 정렬 효과를 제대로 누릴 수 없게 된다. 따라서 인덱스를 설계할 때는 "=" 조건으로 사용될 컬럼을 범위 조건으로 사용될 컬럼보다 앞에 배치하는 것이 일반적인 최적화 전략이다.

Ch07. 인덱스 - 인덱스의 단점과 주의사항

webmaster — Sat, 6 Jun 2026 23:06:33 +0900

인덱스는 공짜가 아니다( 인덱스의 단점)

저장 공간 (Storage)

인덱스는 원본 테이블과는 별개로, B-Tree 구조를 가진 물리적인 파일로 디스크에 저장된다.
- 즉, 인덱스를 생성하면 그만큼의 추가 저장 공간이 필요하다.
인덱스는 어떻게 구성하는지에 따라 다르지만, 일반적으로 원본 테이블 크기의 약 10% 내외의 공간을 추가로 차지한다고 알려져 있다.
- 만약 100GB에 달하는 거대한 items 테이블이 있고, 여기에 5개의 인덱스를 추가로 생성한다면?
- 인덱스만으로 약 50GB라는 무시할 수 없는 추가 디스크 공간이 필요하게 된다. 인덱스를 무분별하게 생성하면 디스크 사용량이 계속해서 늘어나는 것을 보게 될 것이다.

쓰기 성능 (INSERT, UPDATE, DELETE)

인덱스는 "SELECT"의 속도를 높이는 대가로, "INSERT", "UPDATE", "DELETE"의 속도를 희생시킨다. 데이터에 변경이 일어날 때마다, 데이터베이스는 원본 테이블뿐만 아니라 이와 관련된 모든 인덱스를 함께 수정해야 하기 때문이다

INSERT: 새로운 상품이 등록되면(INSERT), items 테이블에 행이 추가된다. 동시에, 이 테이블에 생성된 모든 인덱스(예: PRIMARY, seller_id, idx_items_category_price)의 B-Tree에도 새로운 데이터에 대한 키 값과 주소가 추가되어야 한다.
- 이 과정에서 B-Tree의 정렬 순서를 유지하고 균형을 맞추기 위한 추가적인 연산이 발생한다.
- 인덱스가 5개라면, 테이블 삽입 1번에 인덱스 삽입 5번의 작업이 추가되는 셈이다.
DELETE: 상품이 삭제되면(DELETE), 테이블에서 행이 사라진다.
- 동시에 모든 인덱스에서도 해당 상품에 대한 키 값이 삭제되어야 한다.
UPDATE: 상품 정보가 수정될 때가 가장 복잡하다.
- 만약 인덱스가 없는 "stock_quantity" 컬럼의 값이 변경된다면, 인덱스는 수정할 필요가 없으므로 비교적 빠르다.
- 하지만 인덱스가 있는 "price" 컬럼의 값이 변경된다면, 데이터베이스는 기존 "price" 값으로 된 인덱스 항목을 "삭제"하고, 새로운 "price" 값으로 인덱스 항목을 '추가'하는 것과 유사한 작업을 수행한다.
  - 왜냐하면 인덱스는 변경된 값에 맞추어 새로운 정렬 상태를 유지해야 하기 때문이다.
  - 이는 "INSERT"와 "DELETE"가 동시에 발생하는 것과 같아 부하가 크다.

실무 가이드: 균형의 미학

워크로드를 분석하라: 읽기 vs 쓰기

읽기 중심(Read-heavy) 서비스: 데이터 분석 시스템, 블로그, 뉴스 사이트처럼 데이터 변경보다는 조회가 훨씬 더 빈번한 서비스라면, 다양한 조회 성능을 높이기 위해 인덱스를 비교적 자유롭게 생성해도 좋다.
- 우리 쇼핑몰의 상품 조회 기능이 대표적이다.
쓰기 중심(Write-heavy) 서비스: 실시간으로 데이터를 기록하는 로깅 시스템, 주식 거래 시스템, 채팅 서비스처럼 "INSERT" 나 "UPDATE"가 매우 빈번한 서비스라면, 인덱스 생성에 매우 신중하고 보수적이어야 한다.
- 모든 인덱스는 쓰기 작업에 오버헤드를 추가하기 때문이다.
- 꼭 필요한 최소한의 인덱스만 유지해야 한다.

"혹시나 해서" 인덱스를 만들지 마라.

사용하지 않는 인덱스는 저장 공간만 차지하고 쓰기 성능만 저하시키는 암적인 존재다. 명확한 목적 없이, "나중에 쓸 것 같아서"라는 이유로 인덱스를 미리 만드는 것은 좋지 않다. 느린 쿼리가 발견되었을 때, 그 쿼리를 개선하기 위한 목적으로 생성해야 한다.

사용하지 않는 인덱스는 주기적으로 정리하라.

대부분의 데이터베이스는 특정 인덱스가 얼마나 사용되었는지 모니터링하는 기능을 제공한다. 몇 달, 혹은 1년 이상 아무도 사용하지 않는 인덱스가 있다면, 과감하게 삭제하여 시스템 자원을 확보하고 쓰기 성능을 높여야 한다.

인덱스 컬럼은 가공하면 안 된다.

WHERE 절에서 인덱스가 적용된 컬럼을 함수로 감싸거나 계산을 하는 등 가공하게 되면 인덱스가 적용되지 않는다. 이는 실무에서 정말 자주 하는 실수이므로 반드시 기억해야 한다.

예를 들어 WHERE 절에서 인덱스가 적용된 컬럼에 "SUBSTRING()" 같은 함수를 사용하거나 연산을 하면 인덱스가 작동하지 않아 테이블 전체를 스캔하게 되므로 성능이 크게 저하된다.

문제: "WHERE SUBSTRING(item_name, 1, 5) = '게이밍'"처럼 인덱스 컬럼(item_name)을 가공하면, 데이터베이스는 정렬된 인덱스를 활용하지 못하고 모든 데이터를 일일이 확인한다.
- "WHERE indexed_column * 10 = 100" 이런 경우도 마찬가지로 인덱스를 사용하지 못한다.

원인: 인덱스는 가공되지 않은 원본 값을 기준으로 만들어지기 때문이다.

해결책: 컬럼 자체를 가공하는 대신, LIKE 연산자를 사용하여 "WHERE item_name LIKE '게이밍%'"와 같이 조건을 변경해야 인덱스를 효율적으로 사용할 수 있다.

결론: SQL 성능을 높이려면 인덱스 컬럼은 절대 가공하지 말고 원본 상태 그대로 사용해야 한다

Ch07. 인덱스 - 인덱스 설계 가이드라인

webmaster — Sat, 6 Jun 2026 23:06:19 +0900

인덱스를 만드는 법(CREATE INDEX)을 아는 것보다 더 중요한 것은, 어디에 인덱스를 만들어야 하는지 아는 것이다. 잘못된 인덱스는 오히려 시스템 성능을 떨어뜨리는 애물단지가 될 수 있다

인덱스는 결코 공짜가 아니다. 데이터를 추가(INSERT), 수정(UPDATE), 삭제(DELETE)할 때마다 인덱스도 함께 변경되어야 하므로 쓰기 성능이 저하되고, 별도의 저장 공간도 차지한다. 따라서 우리는 이 비용을 상쇄하고도 남을 만큼의 "검색 성능 향상"이라는 이득을 얻을 수 있는 곳에만 전략적으로 인덱스를 생성해야 한다.

핵심 원칙: 카디널리티 (Cardinality)

인덱스를 어디에 걸지 판단하는 가장 중요한 기준은 바로 카디널리티(Cardinality)다. 카디널리티란, 해당 컬럼에 저장된 값들의 고유성(uniqueness) 정도를 나타내는 지표다.

카디널리티가 높다 (High Cardinality): 해당 컬럼에 중복되는 값이 거의 없다는 의미다.
- 예: items 테이블의 "item_id", "item_name"
카디널리티가 낮다 (Low Cardinality): 해당 컬럼의 값이 몇 종류 안되어 중복되는 값이 많다는 의미다.
- 예: items 테이블의 category(5종류), is_active(2종류)

인덱스는 "찾아보기"다. 찾아보기가 효과적이려면, 특정 키워드를 찾았을 때 검색 범위가 확!!! 줄어들어야 한다. items 테이블에서 "WHERE is_active = TRUE"라는 조건으로 검색한다고 생각해 보자. `is_active` 컬럼에 인

덱스가 있더라도, `TRUE` 인 데이터가 전체의 80%라면, 데이터베이스는 인덱스를 통해 전체 데이터의 80%를 스캔해야

한다. 이런 경우 데이터베이스 옵티마이저는 "이럴 바엔 그냥 풀 테이블 스캔하는 게 낫겠다"고 판단할 수 있다.

반면 `WHERE item_name = '게이밍 노트북'

` 은 어떤가? 인덱스는 수십만 건의 상품 데이터 중 단 1건으로 검색 범위를 완벽하게 좁혀준다.

핵심 규칙: 인덱스는 카디널리티가 높은, 즉 식별력이 좋은 컬럼에 생성할 때 가장 효율적이다.

인덱스 생성 가이드라인

WHERE 절에서 자주 사용되는 컬럼

가장 기본적이고 명백한 가이드라인이다. 인덱스의 존재 이유 자체가 "WHERE" 절의 검색 속도를 높이는 것이기 때문이다.
사용자들이 상품을 검색할 때 "items.item_name"으로 검색하거나, 특정 카테고리(items.category)를 필터링한다면 이 컬럼들은 인덱스 생성의 우선 후보가 된다.

JOIN의 연결고리가 되는 컬럼 (외래 키)

JOIN의 성능은 연결고리가 되는 컬럼에 인덱스가 있는지 여부에 따라 극적으로 달라진다. '행복쇼핑' 판매자가 등록한 모든 상품을 조회하는 쿼리를 예로 들어보자.

select 
	s.seller_name,
    i.item_name,
    i.price
from items  i
join sellers s on i.seller_id = s.seller_id
where s.seller_name = '행복쇼핑';

"items.seller_id"에 인덱스가 없을 때
- 만약 items 테이블의 "seller_id" 컬럼(외래 키)에 인덱스가 없다면, 데이터베이스는 다음과 같이 비효율적으로 동작한다
  1. sellers 테이블에서 "seller_name"이 '행복쇼핑'인 판매자를 찾는다. (seller_id = 1)
  2. items 테이블의 모든 행을 처음부터 끝까지 스캔하면서, "seller_id"가 "1"인 상품을 하나씩 찾아낸다.
- 풀 테이블 스캔이 발생한다.
"items.seller_id"에 인덱스가 있을 때
- 다행히 "items.seller_id"에는 외래 키 제약 조건 덕분에 인덱스가 자동으로 생성되어 있다. 인덱스가 있을 때의 동작은 완전히 다르다.
  1. sellers 테이블에서 "seller_name"이 '행복쇼핑'인 판매자를 찾는다.(seller_id = 1)
  2. "items.seller_id" 인덱스를 사용하여 "seller_id"가 "1"인 상품 데이터의 위치를 곧바로 찾아낸다.
- 풀 테이블 스캔이 사라지고 몇 번의 탐색만으로 "JOIN"이 완료된다.

쿼리 실행 결과 확인

explain select 
	s.seller_name,
    i.item_name,
    i.price
from items  i
join sellers s on i.seller_id = s.seller_id
where s.seller_name = '행복쇼핑';

쿼리 결과

items 테이블(i)의 "type"이 "ref"이고, "key"가 "fk_items_sellers"인 것을 볼 수 있다.
- 이는 JOIN 과정에서 items 테이블을 조회할 때 "seller_id" 인덱스를 매우 효율적으로 사용했다는 증거다.

따라서 JOIN에 사용되는 외래 키(Foreign Key) 컬럼에는 반드시 인덱스를 생성해야 한다.

MySQL은 외래 키 제약조건을 설정하면 인덱스를 자동으로 생성한다.

종종 외래 키 제약조건을 걸지 않고 데이터베이스를 사용하는 경우도 있다. 이때는 조인 성능을 위해 외래키로 사용되는 컬럼에 반드시 인덱스를 직접 생성해야 한다

ORDER BY 절에서 자주 사용되는 컬럼

"ORDER BY"를 사용한 정렬은 데이터의 양이 많을 경우 매우 비용이 큰 작업이다. 데이터베이스는 결과를 반환하기 전에 모든 데이터를 메모리에 올리고 정렬해야 하기 때문이다.

만약 "ORDER BY"에 사용된 컬럼에 인덱스가 있다면 어떨까? B-Tree 인덱스는 이미 데이터가 정렬된 상태로 저장되어 있다. 데이터베이스는 굳이 데이터를 따로 정렬할 필요 없이, 인덱스에 있는 순서 그대로 데이터를 읽기만 하면 된다. 비용이 큰 정렬 작업(filesort)을 완전히 건너뛸 수 있는 것이다. "최신 등록 상품 목록 10개"를 보여주는 "ORDER BY registered_date DESC LIMIT 10"과 같은 쿼리는"registered_date" 컬럼에 인덱스가 있을 때 엄청난 성능 향상을 기대할 수 있다.

Ch07. 인덱스 - 복합 인덱스(1)

webmaster — Sat, 6 Jun 2026 23:06:00 +0900

"카테고리가 '전자기기'인 상품들 중에 가격이 100,000원 이상인 상품을 보여줘" 이러한 요구사항이 들어왔다.

SELECT * FROM items
WHERE category = '전자기기' AND price >= 100000

다중 조건 쿼리의 성능을 최적화하기 위해 사용하는 것이 바로 복합 인덱스(Composite Index) 또는 다중 컬럼 인덱스(Multi-column Index)다.
복합 인덱스는 이름 그대로 두 개 이상의 컬럼을 묶어서 하나의 인덱스로 만드는 것이다
하지만 복합 인덱스를 제대로 사용하려면 한 가지 매우 중요한 규칙을 이해해야 한다. 바로 "컬럼의 순서"다

왜 컬럼 순서가 중요할까?

복합 인덱스의 동작 원리는 우리가 실생활에서 사용하는 "전화번호부"나 "국어사전"과 똑같다.

전화번호부: "성(Last Name)"으로 먼저 정렬된 후, 같은 성 안에서 "이름(First Name)"으로 다시 정렬된다.
국어사전: "첫 번째 글자"로 먼저 정렬된 후, 같은 첫 글자로 시작하는 단어들끼리 "두 번째 글자"로 다시 정렬된다.

items 테이블에 "(category, price)" 순서로 복합 인덱스를 만들었다고 상상해 보자. 이 인덱스는 내부적으로 다음과 같이 정렬된다.

category를 기준으로 먼저 정렬한다. ('도서', '생활용품', '전자기기', '패션', '헬스/뷰티' 순서)
같은 category 내에서는 "price"를 기준으로 다시 정렬한다.

예시

category로 검색: 매우 효율적이다. 인덱스의 앞부분만 보고 빠르게 찾을 수 있다. (예: "전자기기" 섹션으로 바로 점프)
category와 price로 검색: 역시 매우 효율적이다. "전자기기" 섹션을 찾은 뒤, 그 안에서 "price" 순으로 정렬된 데이터를 탐색하면 된다.
- "전자기기" 안에서는 "price"가 항상 정렬된 상태를 유지한다.
- 각각의 카테고리 안에서는 "price"가 항상 정렬된 상태를 유지한다.
- "1차 정렬"의 기준 안에서 "2차 정렬"은 항상 정렬된 상태를 유지한다.
price만으로 검색: 매우 비효율적이다. 전화번호부에서 성은 모르고 이름 만으로 찾는 것과 같다.
- price 값은 각 "category" 섹션마다 흩어져 있기 때문에, 인덱스 전체를 다 훑어봐야 한다.
- 이런 경우 옵티마이저는 차라리 풀 테이블 스캔을 선택할 수도 있다.

"idx_items_category_price" 인덱스 예시에서 price 컬럼만 딱 분류해서 보자. 가격순으로 정렬이 되어 있는 것같아 보이지만 중간에 정렬이 다시 틀어진다. 결과적으로 "price" 컬럼만 보면 정렬이 되어 있지 않다. 결과적으로 1차 정렬의 기준 없이 2차 정렬의 값만 가지고는 정렬된 상태를 유지할 수 없다.

이처럼 복합 인덱스는 첫 번째 컬럼을 기준으로 정렬된 상태에서만 제 역할을 할 수 있다. 이를 인덱스 왼쪽 접두어 규칙(Index Left-Prefix Rule)이라고 한다. 인덱스를 "(A, B, C)" 순서로 생성했다면, "WHERE" 조건에 다음과 같이 사용될 때 효율적이다.

(A)
(A, B)
(A, B, C)

하지만 "(B), (C), (B, C)"와 와 같이 첫 번째 기준인 "A"가 빠진 조건으로는 인덱스를 제대로 활용할 수 없다.

복합 인덱스 대원칙

인덱스는 순서대로 사용하라!(왼쪽 접두어 규칙)
등호(=) 조건은 앞으로, 범위 조건(<, >)은 뒤로!
정렬(ORDER BY)도 인덱스 순서를 따르라!

Index 생성하기

create index idx_items_category_price on items(category, price);

show index from items;

쿼리 결과

"idx_items_category_price"는 하나의 복합 인덱스이다.
"Seq_in_index"는 복합 인덱스의 컬럼 순서를 나타낸다.
- "idx_items_category_price"의 경우 1번은 "category" , 2번은 "price" 순서로 만들어진 것을 확인할 수 있다.

복합 인덱스 성공 예제1: category 사용

explain select * from items where category = '전자기기';

쿼리 결과

쿼리 동작 과정

type(ref): category가 '전자기기'인 조건을 만족하는 데이터를 찾기 위해 동등 비교(= )나 "JOIN"을 사용하고, 인덱스를 효율적으로 사용했음을 의미한다.
- 쉽게 이야기해서 Key 값 하나를 딱 집어서 찾은 것이다.
key(idx_items_category_price): 우리가 만든 복합 인덱스가 사용되었다.
rows(10): 옵티마이저는 '전자기기' 카테고리에 해당하는 상품이 약 10건 있을 것으로 정확히 예측하고, 그 부분만 탐색한다.

이는 (category, price)로 정렬된 인덱스에서 category가 '전자기기'인 첫 번째 위치를 빠르게 찾아낸 뒤, '전자기기'가 끝날 때까지 인덱스를 순차적으로 읽기만 하면 되므로 매우 효율적이다. 전화번호부에서 "김"씨를 찾는 것과 같이, "ㄱ" 섹션으로 바로 이동해서 "김"씨가 끝날 때까지 읽는 것과 같다.

복합 인덱스 성공 예제 2: category, price 사용

"카테고리가 '전자기기'이면서, 가격이 정확히 120,000원인 상품을 찾아보자."

explain select * from items where category = '전자기기' and price = 120000;

쿼리 결과

type(ref): 두 개의 컬럼 조건(category, price)을 모두 만족하는 데이터를 찾기 위해 인덱스를 사용했다
rows(1): 탐색할 행의 수가 단 "1개"로 예측된다.

데이터베이스는 먼저 category가 '전자기기'인 섹션을 찾고, 그 안에서 price가 '120000'인 지점을 탐색한다. '전자기기' 섹션 내부는 이미 "price" 순으로 정렬되어 있으므로, 원하는 데이터를 매우 빠르게 특정할 수 있다.

복합 인덱스 성공 예제 3: 복합 인덱스와 정렬

복합 인덱스의 진정한 힘은 정렬(ORDER BY) 작업을 피할 때 드러난다. "WHERE" 절의 필터링과 "ORDER BY"의 정렬 방향이 인덱스 순서와 일치하면, 데이터베이스는 불필요한 filesort 작업을 생략해서 성능을 크게 향상 시킬 수 있다.

"카테고리가 '전자기기'이면서 100,000원 초과인 상품을 가격 오름차순으로 정렬해서 보여줘." 요구 사항을 생각해 보자

explain select * from items where category = '전자기기' and price > 100000
order by price;

쿼리 결과

Extra 컬럼에 "Using filesort"가 없다.

쿼리 동작 과정

"idx_items_category_price" 인덱스를 사용해 category가 '전자기기'인 섹션으로 빠르게 이동한다.
해당 섹션 내에서, price가 "100000"을 초과하는 첫 번째 데이터를 찾는다.
그 지점부터 '전자기기' 섹션이 끝날 때까지 인덱스를 순서대로 읽기만 하면 된다

인덱스의 '전자기기' 섹션은 이미 price 순서로 완벽하게 정렬되어 있다. 따라서 데이터베이스는 별도로 데이터를 모아 다시 정렬할 필요 없이, 인덱스를 읽는 즉시 "ORDER BY price" 조건을 만족하는 결과를 얻게 된다. 이처럼 "WHERE" 절의 조건과 "ORDER BY" 절의 조건이 복합 인덱스의 순서(category → price)와 일치하면, 데이터베이스는 가장 효율적인 방식으로 데이터를 찾고 정렬까지 한 번에 처리한다. "filesort"를 피하는 것이야말로 복합 인덱스를 사용하는 핵심적인 이유 중 하나다.

explain select * from items where category = '전자기기' and price > 100000
order by category, price;

쿼리 결과

"ORDER BY"를 사용할 때 복합 인덱스의 순서대로 정렬하면 추가적인 정렬(filesort)을 피할 수 있다
여기서 복합 인덱스가 "category, price" 순서이므로 "ORDER BY"도 순서에 맞추어 사용하면 정렬을 최적화할 수 있다.
여기서 선택된 "category"는 '전자기기' 단 하나이므로 이런 경우에는 "category"를 정렬 조건에 넣을 필요가 없다.
- 정렬은 최소 2개 이상 있을 때 의미가 있다.
- 이런 경우에는 "ORDER BY"에 category를 두는 것이 의미가 없으므로 생략이 가능하다.

다른 필드로 정렬

explain select * from items where category = '전자기기' and price > 100000
order by item_name;

쿼리 결과

만약 "ORDER BY item_name"처럼 인덱스 순서와 다른 컬럼으로 정렬을 요청했다면, 조회한 결과를 다시 정렬해야 하기 때문에 Extra 컬럼에 "Using filesort"가 발생할 것이다.