# Mysql Tuning Skill

> MySQL 쿼리 성능 튜닝 및 최적화 스킬. MySQL 쿼리가 느린 경우, 실행계획(EXPLAIN) 분석, 인덱스 설계/최적화, 조인 튜닝, 서브쿼리 변환, 파티션 적용, 슬로우 쿼리 분석, Lock/트랜잭션 문제 해결 등 모든 MySQL 성능 관련 작업에 사용한다. "쿼리가 느려요", "EXPLAIN 결과 해석", "인덱스를 어떻게 잡아야 하나", "풀스캔이 발생해요", "조인 순서 최적화", "대용량 테이블 튜닝", "DB 성능 개선", "MySQL 최적화" 등의 요청에 반드시 이 스킬을 사용할 것.

- Skill: `mineru98/mysql-tuning-skill` (Agent Skill, multi-file: 9 files)
- Install (CLI): `npx skillmds@latest add mineru98/mysql-tuning-skill`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mineru98/mysql-tuning-skill/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Mineru98 (https://skillmd.com/u/mineru98)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mineru98/mysql-tuning-skill

---


# MySQL 성능 튜닝 스킬

## 개요

이 스킬은 MySQL 쿼리 성능 문제를 진단하고 해결하는 데 필요한 레퍼런스를 제공한다. 사용자의 요청에 따라 아래 레퍼런스 파일 중 필요한 것만 선택적으로 읽어서 활용한다.

## 레퍼런스 파일 구조

| 파일 | 내용 | 이런 경우 읽을 것 |
|------|------|-------------------|
| `reference/01-explain.md` | EXPLAIN 실행계획 읽는 법 | 실행계획 해석, type/Extra 의미 질문, EXPLAIN 결과 분석 요청 |
| `reference/02-index.md` | 인덱스 원리 및 설계 | 인덱스 생성/최적화, 커버링 인덱스, 복합 인덱스 순서, 선택도/카디널리티 |
| `reference/03-query-patterns.md` | 실전 쿼리 튜닝 패턴 | 좌변 함수 제거, OR→IN 변환, 스칼라→JOIN, 페이징, 대량 DML 등 구체적 SQL 최적화 |
| `reference/04-join.md` | 조인 전략 및 순서 최적화 | 조인이 느린 경우, 드라이빙 테이블, Hash Join, STRAIGHT_JOIN |
| `reference/05-transaction-lock.md` | 트랜잭션/Lock/동시성 | Lock 대기, Deadlock, 격리 수준, MVCC, Gap Lock |
| `reference/06-config-monitoring.md` | 시스템 설정 및 모니터링 | 슬로우 쿼리 로그, 통계 갱신, buffer pool, 시스템 변수 튜닝 |
| `reference/07-checklist.md` | 튜닝 체크리스트 | 종합 진단, 어디서부터 시작할지 모를 때, 전체 점검 |

## 사용 흐름

1. 사용자의 요청을 파악한다
2. 관련된 레퍼런스 파일을 `view` 도구로 읽는다 (여러 파일이 필요하면 복수 로드)
3. 레퍼런스의 내용을 바탕으로 구체적인 진단과 해결책을 제시한다

## 핵심 원칙

이 원칙들은 모든 레퍼런스에 공통으로 적용된다:

- **EXPLAIN 먼저**: 튜닝은 항상 실행계획 확인에서 시작한다
- **인덱스 컬럼을 가공하지 말 것**: 좌변(컬럼)에 함수/연산을 적용하면 인덱스를 탈 수 없다. 우변(비교값)을 가공하라
- **작은 결과집합을 드라이빙 테이블로**: 조인 시 결과 건수가 적은 쪽을 먼저 읽어야 한다
- **커버링 인덱스 우선**: 데이터 파일 접근 없이 인덱스만으로 결과를 반환할 수 있으면 최선이다
- **통계 정보를 최신으로**: 옵티마이저는 통계 기반으로 판단하므로 대량 DML 후에는 `ANALYZE TABLE` 실행

## 빠른 진단 가이드

사용자가 "쿼리가 느려요" 혹은 "쿼리 개선해줘" 라고 말하면, 이 순서로 진단한다:

```
1. EXPLAIN으로 실행계획 확인 → 01-explain.md
   - type=ALL이면 → 02-index.md (인덱스 확인)
   - Using temporary/filesort → 03-query-patterns.md (쿼리 패턴 확인)

2. 인덱스가 있는데도 안 타면 → 03-query-patterns.md
   - 좌변 함수? 암묵적 형변환? LIKE '%...'?

3. 조인이 느리면 → 04-join.md
   - 드라이빙 테이블 순서? 드리븐 테이블에 인덱스?

4. 쿼리 자체는 빠른데 느리면 → 05-transaction-lock.md
   - Lock 대기? 트랜잭션이 길어진 건 아닌지?

5. 전반적 느림 → 06-config-monitoring.md
   - buffer pool 크기? 슬로우 쿼리 로그 분석?
```