MariaDB는 왜 느려질까? 인덱스와 성능 최적화 기초

 

 

※ 이 글은 운영자가 직접 홈서버를 실험해보고, MariaDB 공식 문서도 꼼꼼히 참고해서 쓴 내용입니다. 문장 정리와 구성에는 AI 도구의 도움을 조금 받았지만, 최종적으로 모든 내용은 운영자가 하나하나 직접 확인하고 검토했습니다.

MariaDB는 왜 느려질까? 인덱스와 성능 최적화 기초

도입

6주차 월요일에는 홈서버에 가장 적합한 데이터베이스가 무엇인지 비교해봤어요. 화요일에는 Docker Compose를 이용해 MariaDB를 직접 설치해 봤고요. 수요일에는 사용자와 권한을 설정하면서 겪을 수 있는 접속 문제들을 정리해두었습니다.

목요일에는 MariaDB의 성능과 인덱스의 기본 개념에 대해 이야기해 보려고 합니다. 처음 데이터베이스를 만들었을 땐 저장된 데이터가 적어서 주로 빠르게 동작합니다. 하지만 시간이 지나 데이터가 많아지고, 검색 조건이 복잡해지거나 여러 서비스가 동시에 데이터를 조회하게 되면, 점점 응답 속도가 달라지는 걸 느끼게 됩니다.

이번 글의 핵심은 고급 튜닝이 아닙니다. 홈서버 운영자가 알아두면 좋은 인덱스의 기본 개념, 검색이 느려지는 이유, EXPLAIN으로 실행 계획을 확인하는 흐름을 정리하는 것이 목적입니다. 데이터베이스는 저장보다 찾는 속도가 더 중요해지는 순간이 있었습니다.

MariaDB 인덱스 구조와 EXPLAIN 실행 계획을 통해 검색 성능을 점검하는 Intel N100 홈서버 운영 다이어그램입니다.

※ 다이어그램은 운영 환경 설계를 바탕으로 AI 도구를 활용해 제작했으며, 최종 구성과 내용은 운영자가 직접 검수했습니다.
출처: 디지털 장난감

본문

데이터베이스는 왜 느려질까?

MariaDB를 처음 설치해서 간단한 테스트 데이터만 입력했을 때는 대부분의 작업이 아주 빠르게 느껴집니다. 데이터가 몇 개 없으니 검색해야 할 양도 적고, 조건을 확인하는 데 드는 시간도 자연스럽게 짧아지기 때문이죠.

하지만 시간이 흐를수록 데이터도 점점 많아집니다. 이용하는 사람이 늘고, 게시글이나 로그도 차곡차곡 쌓이죠. 파일 목록이나 실행 기록까지 다양해지다 보면, 똑같은 검색을 하더라도 살펴봐야 할 데이터의 양이 예전과는 확연히 달라집니다.

• 데이터 양이 늘어납니다.
• 검색 조건이 복잡해집니다.
• 동시에 접근하는 서비스가 늘어납니다.
• 정렬, 필터링, 조인 같은 작업이 많아집니다.
• 불필요한 전체 스캔이 발생할 수 있습니다.

홈서버 환경에서는 대기업처럼 수백만 건의 데이터를 다루는 경우가 흔치 않습니다. 하지만 데이터베이스가 데이터를 어떤 방식으로 찾는지 미리 알아두면, 나중에 속도가 느려졌을 때 원인을 파악하는 데 큰 도움이 됩니다.

인덱스는 책의 목차와 비슷했다

인덱스는 데이터베이스에서 정보를 더 빨리 찾을 수 있도록 도와주는 구조입니다. 쉽게 말해, 책의 목차나 색인과 비슷하다고 보면 됩니다. 예를 들어 책에서 특정 단어를 찾으려면 처음부터 끝까지 페이지를 다 뒤질 필요 없이, 색인 부분을 찾아 해당 페이지로 바로 갈 수 있죠. 이렇게 인덱스가 있으면 원하는 데이터를 훨씬 빠르고 효율적으로 찾을 수 있습니다.

데이터베이스도 마찬가지예요. 특정 컬럼에 인덱스를 걸어두면, MariaDB는 모든 행을 처음부터 끝까지 하나하나 뒤지지 않고, 인덱스를 활용해서 원하는 데이터를 훨씬 더 빨리 찾아냅니다.

인덱스 없음
↓
전체 데이터 확인 가능성 증가

인덱스 있음
↓
검색 대상 범위 축소 가능

인덱스가 모든 문제를 다 해결해 주지는 않습니다. 어떤 컬럼에 인덱스를 적용할지, 그리고 어떤 쿼리가 자주 사용되는지에 따라 그 효과가 달라질 수 있습니다.

인덱스가 없는 검색 예시

예를 들어 사용자 테이블에서 이메일 주소로 사용자를 찾는 쿼리를 생각해볼 수 있습니다.

SELECT *
FROM users
WHERE email = 'user@example.com';

만약 email 컬럼에 인덱스가 없다면, MariaDB는 조건에 맞는 값을 찾기 위해 더 많은 데이터를 확인해야 할 수 있습니다. 데이터가 적을 때는 큰 차이가 없지만, 데이터가 많아질수록 검색 비용이 커질 수 있습니다.

홈서버의 경우 사용자 수가 많지 않아도, WordPress나 Nextcloud, n8n처럼 내부적으로 테이블과 쿼리가 다양한 서비스에서는 인덱스가 있는지에 따라 응답 속도가 달라질 수 있습니다. 인덱스가 없다면 원하는 데이터를 찾는 데 시간이 더 걸릴 수 있어 체감 속도가 느려질 수 있죠.

인덱스 만들기

특정 컬럼에 인덱스를 만들려면 CREATE INDEX 명령을 사용할 수 있습니다. 아래 예시는 users 테이블의 email 컬럼에 인덱스를 만드는 예시입니다.

CREATE INDEX idx_users_email
ON users(email);

이렇게 하면 MariaDB가 이메일 조건을 검색할 때 해당 인덱스를 활용할 수 있습니다. 인덱스 이름은 나중에 관리하기 쉽도록 테이블명과 컬럼명을 함께 넣어서 정해두는 것이 좋습니다.

• idx_users_email : users 테이블의 email 컬럼 인덱스
• idx_posts_slug : posts 테이블의 slug 컬럼 인덱스
• idx_logs_created_at : logs 테이블의 created_at 컬럼 인덱스

하지만 자동으로 생성된 테이블에 인덱스를 임의로 추가할 때는 신중해야 합니다. 서비스가 업데이트되거나 공식 권장 구조와 충돌하는 상황이 생길 수 있기 때문입니다. 실제 운영 데이터베이스라면, 먼저 관련 문서를 꼼꼼히 확인하고 백업 상태도 꼭 점검하는 것이 안전합니다.

인덱스를 너무 많이 만들면 생기는 문제

인덱스가 검색 속도를 높여주긴 하지만, 그렇다고 해서 모든 컬럼에 인덱스를 만드는 것이 좋은 선택은 아닙니다. 인덱스 역시 저장 공간을 차지하고, 데이터가 추가되거나 변경될 때마다 같이 업데이트해야 하기 때문입니다.

상황	장점	주의할 점
자주 검색하는 컬럼에 인덱스	검색 속도 향상 가능	쿼리 패턴 확인 필요
모든 컬럼에 인덱스	겉보기에는 안전해 보임	저장 공간 증가, 쓰기 성능 저하 가능
거의 검색하지 않는 컬럼에 인덱스	효과가 적음	관리 부담만 늘 수 있음

홈서버 운영에서는 “많이 만들수록 좋다”보다 “자주 찾는 컬럼에 필요한 만큼 만든다”는 기준이 더 현실적이었습니다.

EXPLAIN으로 실행 계획 확인하기

쿼리가 어떤 방식으로 실행되는지 확인하려면 EXPLAIN을 사용할 수 있습니다. EXPLAIN은 MariaDB가 해당 쿼리를 어떻게 처리할지 보여주는 도구입니다.

EXPLAIN
SELECT *
FROM users
WHERE email = 'user@example.com';

실행 결과를 보면 실제로 어떤 테이블을 읽고 있는지, 또 어떤 인덱스가 사용되는지, 대략 몇 개의 행을 처리할지 예상할 수 있습니다. 처음 접하는 사람에게는 이런 정보들이 조금 복잡하게 느껴질 수 있지만, 우선 '인덱스를 사용하고 있는지'만 확인해도 큰 도움이 됩니다.

• possible_keys : 사용할 수 있는 인덱스 후보
• key : 실제 선택된 인덱스
• rows : 확인할 것으로 예상되는 행 수
• type : 접근 방식의 대략적인 성격

운영 환경에서 쿼리가 느리다고 느껴질 때는 감으로 인덱스를 추가하기보다, 먼저 EXPLAIN으로 실행 계획을 확인하는 습관이 필요했습니다.

홈서버에서 체감할 수 있는 최적화 기준

Intel N100 홈서버에서는 대규모 서비스에 맞춘 복잡한 튜닝보다는 기본적인 점검이 훨씬 중요했어요. 특히 Docker 환경에서 MariaDB를 사용할 때는 인덱스 관리뿐만 아니라 데이터가 저장되는 위치, 메모리 사용량, 로그 설정, 백업 같은 부분도 함께 신경 써야 했습니다. 이런 요소들이 모두 성능과 안정성에 영향을 줄 수 있기 때문이죠.

점검 영역	확인 내용	운영 판단
쿼리	자주 실행되는 검색 조건	인덱스 후보 확인
데이터	테이블 크기와 행 수	불필요한 로그 누적 확인
저장소	디스크 사용량과 I/O	DB 데이터 경로 점검
Docker	컨테이너 리소스와 로그	서비스 상태 확인
백업	백업 실행 시간	사용 시간대와 겹치지 않게 조정

결국 MariaDB의 성능을 최적화하는 데에는 단순히 인덱스만 신경 써서는 충분하지 않았습니다. 쿼리 구조, 데이터의 양, 저장소 환경, Docker의 상태, 그리고 백업 작업 등 여러 요소를 함께 살펴보는 것이 훨씬 현실적인 접근이었죠.

실습용 테이블로 인덱스 흐름 이해하기

실제 운영 서비스의 테이블을 바로 수정하기보다, 먼저 실습용 테이블에서 인덱스 개념을 확인하는 편이 안전합니다.

CREATE TABLE users (
  id INT AUTO_INCREMENT PRIMARY KEY,
  username VARCHAR(100),
  email VARCHAR(255),
  created_at DATETIME
);

CREATE INDEX idx_users_email
ON users(email);

이후 이메일 조건으로 조회하는 쿼리에 대해 EXPLAIN을 실행하면, 인덱스가 사용되는지 확인할 수 있습니다.

EXPLAIN
SELECT *
FROM users
WHERE email = 'user@example.com';

이 실습은 실제 성능 차이를 크게 느끼기 위한 것이라기보다, MariaDB가 데이터를 찾을 때 인덱스를 어떻게 참고할 수 있는지 이해하기 위한 과정입니다.

운영 로그

아래 표는 6주차 목요일을 기준으로 정리한 MariaDB의 인덱스 및 성능 점검 항목입니다. 실제로는 데이터 크기, 쿼리 구조, 인덱스 설계, 저장 장치, 그리고 Docker 환경 등에 따라 성능이 달라질 수 있습니다.

점검 항목	확인 방법	운영 판단
검색 조건	WHERE 절 확인	자주 검색되는 컬럼 파악
인덱스 목록	SHOW INDEX FROM table_name;	기존 인덱스 확인
실행 계획	EXPLAIN SELECT ...	인덱스 사용 여부 확인
데이터 크기	테이블 행 수와 저장 용량 확인	데이터 증가 추세 점검
Docker 상태	docker compose ps, docker stats	컨테이너 리소스 상태 확인

에디터의 해석 노트 (Editor's Lab Note)

• 처음에는 데이터베이스가 단순한 저장 공간이라고 생각했습니다.
• 하지만 실제 운영에서는 얼마나 빨리 찾을 수 있는지가 더 중요하게 느껴졌습니다.
• 인덱스는 어렵게 보였지만, 책의 목차라고 생각하니 조금 이해하기 쉬웠습니다.
• 홈서버에서는 고급 튜닝보다 자주 실행되는 검색 조건과 실행 계획을 확인하는 습관이 더 현실적이었습니다.

참고 링크 (References)

1. MariaDB CREATE INDEX
2. MariaDB EXPLAIN
3. MariaDB SHOW INDEX
4. MariaDB Optimization and Tuning
5. docker stats reference

트러블슈팅

문제 : 데이터가 많지 않은데도 검색이 느리게 느껴짐

검색 속도가 느릴 때는 곧바로 서버 성능 문제라고 단정짓기보다는, 먼저 쿼리와 인덱스 상태를 점검하는 게 중요합니다. 특히 조건 검색에 자주 쓰이는 컬럼에 인덱스가 빠져 있거나, MariaDB가 예상보다 훨씬 많은 행을 확인하고 있을 가능성이 있습니다. 이런 부분부터 살펴보면 문제를 더 정확하게 파악할 수 있습니다.

확인 : 실행 계획, 인덱스 존재 여부, 검색 조건을 순서대로 점검

# 실행 계획 확인
EXPLAIN
SELECT *
FROM users
WHERE email = 'user@example.com';

# 인덱스 목록 확인
SHOW INDEX FROM users;

원인 : 인덱스 없음, 조건 검색 증가, 전체 스캔 가능성, 불필요하게 누적된 데이터

해결 : 자주 검색되는 컬럼을 기준으로 인덱스 필요성을 검토하고, 변경 전에는 백업과 테스트 환경을 먼저 확인

CREATE INDEX idx_users_email
ON users(email);

현재 구성에서는 성능 문제가 느껴질 때 감으로 설정을 바꾸기보다, EXPLAIN으로 실행 계획을 확인한 뒤 필요한 인덱스를 검토하는 편이 더 안전했습니다.

마무리

MariaDB 인덱스와 성능 최적화를 정리하면서 새삼 느꼈던 건, 데이터베이스가 단순히 정보를 저장하는 곳에 그치지 않는다는 점이었습니다. 데이터가 많아질수록 정말 중요한 건, 필요한 정보를 얼마나 빠르고 효율적으로 찾아낼 수 있느냐였어요.

화요일에는 MariaDB를 설치하고 준비했어요. 수요일에는 사용자 계정을 만들고 권한도 설정했습니다. 목요일에는 데이터를 더 빠르게 찾으려고 인덱스가 어떻게 작동하는지, 또 실행 계획을 어떻게 확인하는지 알아봤습니다.

이번 목요일을 마무리하면서 내릴 수 있는 결론은 꽤 단순합니다. 데이터베이스는 단순히 정보를 저장하는 공간을 넘어, 필요한 내용을 얼마나 신속하게 찾아낼 수 있느냐에 따라 실제 운영에서의 만족도가 크게 달라집니다. 다음 글에서는 MariaDB의 백업과 복구 전략에 대해 좀 더 쉽게 정리해보겠습니다.