[MySQL] key vs possible_keys vs rows 차이점 제대로 알기 🔍

MySQL에서 EXPLAIN을 활용해 실행계획을 분석할 때 자주 마주치는 컬럼이 바로 key, possible_keys, rows이다. 이 세 가지는 모두 인덱스 사용 여부와 성능 진단에 핵심적인 정보를 제공하지만, 그 의미와 역할은 조금씩 다르다. 정확하게 구분해서 이해하지 못하면 불필요한 튜닝으로 이어질 수 있다.

🔑 key: 실제 사용된 인덱스

key는 MySQL이 실제로 쿼리 실행 시 사용한 인덱스를 나타낸다. 이 컬럼의 값이 NULL이라면 해당 쿼리에서는 인덱스가 사용되지 않았다는 뜻이다.

예시:

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

결과:

key

email_index

여기서 email_index가 실제로 사용된 인덱스이며, 실행 시 활용된 인덱스가 정확히 무엇인지를 보여준다.

✅ key가 NULL인 경우 체크할 항목

• WHERE 조건절이 인덱스를 타고 있는지
• 함수, 계산식 사용 여부
• 데이터가 너무 적어 인덱스 대신 풀스캔 선택 가능성

반응형

🧩 possible_keys: 사용 가능한 인덱스 목록

possible_keys는 MySQL이 해당 쿼리에서 사용할 수 있는 인덱스 후보 목록이다. 실제로 사용되었는지와는 관계가 없으며, 말 그대로 "가능한 인덱스들"을 의미한다.

예시:

EXPLAIN SELECT * FROM orders WHERE order_date BETWEEN '2024-01-01' AND '2024-12-31';

결과:

possible_keys

order_date_idx

하지만 실제로는 key가 NULL일 수도 있다. 이럴 경우에는 다음과 같이 생각해볼 수 있다:

• 인덱스는 후보에 있지만, 조건이 애매하거나 효율이 낮아서 사용되지 않음
• 통계정보상 MySQL이 풀스캔을 더 효율적이라 판단한 경우

💡 possible_keys는 인덱스 설계 가이드라인을 평가하는 기준이기도 하다. 이 값이 NULL이면 인덱스 자체가 존재하지 않거나, 전혀 쓸 수 없는 구조라는 의미다.

📊 rows: 스캔 예측 행 수

rows는 해당 쿼리에서 MySQL이 실제로 읽게 될 것으로 예상되는 행의 수이다. 이 값이 클수록 디스크 접근 비용이 커지고 성능은 저하된다.

예시:

rows

15829

이 말은 조건에 부합하는 데이터를 가져오기 위해 약 1.5만 개의 행을 읽어야 함을 뜻한다.

🧠 rows는 정확한 숫자가 아닌 예측값이다. 따라서 실행 계획만 보고 너무 과민반응할 필요는 없지만, 다른 요소들과 함께 판단하면 충분히 쿼리 병목 여부를 가늠할 수 있는 기준이 된다.

반응형

📌 실전 비교 요약표

컬럼명	의미	주요 체크포인트
key	실제로 사용된 인덱스	NULL이면 인덱스 적용 안됨
possible_keys	사용 가능한 인덱스 후보 목록	NULL이면 인덱스 설계 필요
rows	MySQL이 읽을 것으로 예상하는 행의 수	값이 클수록 성능 저하 가능성 높음

💡 실무 팁: 이런 순서로 점검하자

1. possible_keys를 보고 인덱스 후보가 있는지 먼저 확인
2. key가 비어 있다면 인덱스가 왜 사용되지 않았는지 원인 분석
3. rows가 너무 크다면 스캔 비용 최적화 필요 여부 검토

이러한 과정을 통해 불필요한 인덱스, 비효율적인 조건절, 풀스캔 문제 등을 찾아내고 튜닝할 수 있다.

📚 공식 문서 참고

• https://dev.mysql.com/doc/refman/8.0/en/explain-output.html