MariaDB 성능/특성 정리: MySQL 호환 + 옵티마이저/복제 운영 포인트

MariaDB 성능/특성 정리: MySQL 호환 + 옵티마이저/복제 운영 포인트

이 글은 MariaDB를 성능/운영 관점에서 길게 정리한 개인 노트입니다. 목표는 "지금 느린 이유"를 증거로 좁히고, 재발을 줄이는 체크리스트를 갖추는 것입니다.

전제: 성능은 DB만으로 결정되지 않습니다. 쿼리 패턴, 데이터 분포, 인덱스/스키마, 애플리케이션 트랜잭션 경계, 인프라(IO/네트워크)가 함께 결정합니다. 그래서 이 글은 '성능 모델(어디서 시간이 쓰이나) -> 설계/쿼리 -> 설정 -> 운영' 순서로 정리합니다.

MariaDB는 MySQL 계열이지만 버전/옵티마이저/엔진 차이로 'MySQL 지식 그대로'로는 삐끗할 수 있습니다. 관측과 검증 루프가 핵심입니다.

이 DB를 언제 선택하나

정답은 항상 케이스 바이 케이스지만, 선택을 빠르게 만들기 위해 기준을 먼저 둡니다. 아래에 해당이 많을수록 이 DB를 고려할 만합니다.

- MySQL 호환 기반으로 비용/운영 선택지를 넓히고 싶을 때
- 특정 기능(스토리지 엔진/레플리케이션 옵션)을 활용하고 싶을 때
- MySQL과 유사한 운영을 하되, 버전 차이 검증 문화를 갖출 수 있을 때

성능 모델: 어디서 시간이 쓰이나

MariaDB의 성능도 기본은 쿼리 패턴 + 인덱스 + 캐시입니다. 다만 같은 SQL이라도 옵티마이저의 선택이 다를 수 있고, 버전 차이가 결과를 바꿀 수 있습니다.

그래서 튜닝은 1) 실제 실행 계획 확인, 2) 통계 갱신, 3) 인덱스/쿼리 리라이트, 4) 캐시/버퍼 조정 순서를 지키는 게 안전합니다.

핵심 용어 빠른 사전

성능/장애 분석에서 자주 쓰는 단어는 팀마다 다르게 이해되기 쉽습니다. 용어를 짧게 정의하고, 어떤 지표/증상과 연결되는지 같이 적어둡니다.

용어	설명	실무에서 연결되는 것
Optimizer	실행 계획을 고르는 엔진	통계/버전 차이로 계획이 달라져 성능이 요동
Statistics	데이터 분포 정보	rows 추정이 틀리면 잘못된 조인/스캔 선택
InnoDB Buffer Pool	데이터/인덱스 캐시	캐시 미스가 나면 디스크 IO로 지연 증가
Binlog	복제/CDC 로그	복제 구성에서 지연/내구성과 연결
Replica Lag	복제 적용 지연	읽기 분산 시 일관성 문제로 직결

옵션/핵심 요소(3~6)

자주 부딪히는 핵심 요소를 표로 먼저 고정해 두면, 장애/튜닝 때 팀 커뮤니케이션이 빨라집니다.

항목	의미	언제 쓰는지(실무 상황)
EXPLAIN	실행 계획 확인	인덱스가 제대로 쓰이는지 검증
ANALYZE TABLE	통계 갱신	rows 추정이 틀리거나 계획이 흔들릴 때
slow_query_log	느린 쿼리 기록	병목 후보를 데이터로 뽑을 때
innodb_buffer_pool_size	버퍼 풀	읽기 IO를 줄이고 캐시 효율을 올릴 때
binlog	복제/CDC 기반 로그	복제/감사/백업 요구가 있을 때
Replica Lag	복제 지연	읽기 분산/DR 구성에서 정합성 이슈 관리

실무 튜닝 포인트(설정/옵션별)

설정에는 정답이 없습니다. 워크로드(읽기/쓰기/동시성/데이터 크기) 기준으로 관측하고 조정합니다. 아래는 실무에서 가장 자주 만지는 레버를 '항목별'로 정리한 것입니다.

innodb_buffer_pool_size
의미: 핵심 캐시
언제 만지나: 디스크 read가 많고 메모리 여유가 있을 때
주의/트레이드오프: 너무 키우면 스왑/OS 캐시 경쟁

innodb_log_file_size
의미: redo log 크기
언제 만지나: 쓰기 burst에서 checkpoint/flush가 잦을 때
주의/트레이드오프: 복구 시간 증가 가능

optimizer_switch
의미: 옵티마이저 전략 토글
언제 만지나: 특정 쿼리에서 계획이 비정상적으로 선택될 때
주의/트레이드오프: 전역 토글은 회귀 위험, 변경은 최소화

join_buffer_size
의미: 조인 버퍼(세션 단위)
언제 만지나: 인덱스 없는 조인을 완화해야 할 때
주의/트레이드오프: 세션 단위라 동시성에서 메모리 급증

tmp_table_size
의미: 임시 테이블 메모리 한도
언제 만지나: Using temporary가 잦을 때
주의/트레이드오프: 동시 쿼리에서 메모리 급증

max_connections
의미: 동시 연결 상한
언제 만지나: 연결 폭증을 제한하고 풀링으로 유도
주의/트레이드오프: 상한을 늘리는 건 근본 해결이 아님

binlog_format
의미: binlog 포맷
언제 만지나: 복제/CDC 요구에 맞출 때
주의/트레이드오프: row 기반은 로그/스토리지 증가

sync_binlog
의미: binlog 동기화 정책
언제 만지나: 내구성과 지연을 조절해야 할 때
주의/트레이드오프: 값에 따라 장애 시 유실 가능성 변화

쿼리/스키마 설계에서 성능이 갈리는 지점

MariaDB에서도 인덱스 설계가 가장 큰 레버입니다. 복합 인덱스는 좌측(prefix) 규칙을 지키고, 정렬/범위 조건에 맞춰 컬럼 순서를 결정합니다.

복제를 쓴다면 큰 트랜잭션/배치가 replica lag를 만들 수 있고, lag는 읽기 라우팅에서 일관성 이슈로 번집니다. 즉, 복제는 운영/기능 설계와 같이 가야 합니다.

EXPLAIN SELECT * FROM events WHERE tenant_id=10 AND created_at >= NOW() - INTERVAL 7 DAY ORDER BY created_at DESC LIMIT 100;
CREATE INDEX idx_events_tenant_created ON events (tenant_id, created_at DESC);
ANALYZE TABLE events;

진단 명령/쿼리 모음(바로 실행용)

장애 때는 문서 찾을 시간이 없습니다. 아래는 현장에서 자주 쓰는 '첫 5분' 진단 명령/쿼리만 모은 것입니다. 환경/권한에 따라 일부는 제한될 수 있습니다.

SHOW FULL PROCESSLIST;
SHOW ENGINE INNODB STATUS\G
EXPLAIN SELECT 1;
ANALYZE TABLE events;
-- 복제 지연/상태는 구성에 따라 확인 방법이 다를 수 있음(Replica 상태 점검을 표준화)

자주 하는 실수(운영/튜닝)

실수 체크리스트:
- MySQL과 동일하다고 가정하고 버전 차이/옵티마이저 차이를 검증하지 않는다
- slow query/EXPLAIN 없이 설정부터 만진다
- 복합 인덱스 설계를 쿼리 패턴이 아니라 감으로 만든다
- 복제 지연을 모니터링하지 않고 읽기 분산을 한다
- 큰 배치 트랜잭션으로 replica lag를 폭발시킨다
- 불필요한 인덱스를 방치해 쓰기 비용을 키운다

운영/모니터링 체크리스트

운영에서는 slow query 상위, 버퍼 풀/디스크 IO, 락 대기/데드락, 복제 지연, 백업/복구 시간을 핵심으로 둡니다.

공통 체크리스트:
- 느린 쿼리 top N을 지속 수집(시간/호출수/총시간)
- 지연(p95/p99)과 오류율을 애플리케이션 지표와 함께 본다
- 캐시/메모리/디스크 IO 중 무엇이 병목인지 먼저 분리한다
- 복제/HA를 쓰면 일관성 요구가 높은 기능을 분리한다
- 튜닝/변경 후에는 동일 조건으로 재측정해 회귀를 막는다

트러블슈팅 루틴(순서 고정)

장애 때는 선택지가 너무 많아서 흔히 길을 잃습니다. 아래 순서를 팀 표준으로 정해두면, 원인 추적이 빨라지고 '감으로 설정만 만지는' 일을 줄일 수 있습니다.

1) 느린 쿼리를 slow_log에서 고른다
2) EXPLAIN으로 계획/rows 추정을 확인한다
3) 통계(ANALYZE)와 인덱스 설계를 먼저 정리한다
4) temporary/filesort가 뜨면 정렬/범위 조건을 재검토한다
5) 쓰기 지연은 redo/flush/락 대기를 분리해 본다
6) 복제 사용 시 replica lag와 큰 트랜잭션을 점검한다

문제 상황(정확히 1개)

상황 -> 리더(Replica)로 읽기 분산을 했더니 특정 화면에서 데이터가 간헐적으로 늦게 보인다.
원인 -> replica lag가 발생했고, 일관성 요구가 있는 기능까지 Replica로 라우팅됐다.
해결 -> 일관성 요구가 있는 기능은 Primary로 라우팅하고, lag를 알람화하며 큰 트랜잭션을 쪼갠다.
예방 팁 -> 기능별 읽기 일관성 정책(Primary/Replica)을 문서화하고, lag 초과 시 자동 우회 규칙을 둔다.

참고/출처

정확한 동작/버전별 차이는 공식 문서를 기준으로 확인합니다. 실무에서는 버전 차이가 곧 성능/장애 차이입니다.

• MariaDB Documentation
• MariaDB: EXPLAIN