예시 답변 1
약 65초
경험 기반 구체화
Oracle이나 MySQL을 사용한 경험은 학교 DB 수업에서 MySQL로 데이터베이스를 설계하고 쿼리를 최적화한 것입니다. 주문 이력 데이터를 대상으로 복잡한 조인 쿼리 성능이 떨어지는 문제를 만났는데, EXPLAIN으로 실행 계획을 분석하자 전체 테이블 스캔이 발생하는 것을 확인했습니다. 자주 조회되는 컬럼 조합에 복합 인덱스를 추가하자 응답 시간이 8초에서 0.5초로 줄었습니다. 이 경험에서 인덱스는 읽기 성능을 높이지만 쓰기 성능과 저장 공간에 비용이 생긴다는 트레이드오프도 배웠습니다. 또 불필요한 SELECT * 대신 필요한 컬럼만 명시하는 것이 쿼리 성능을 높이는 기본이고, 서브쿼리를 JOIN으로 바꾸면 옵티마이저가 더 효율적인 계획을 선택하는 경우가 많다는 것도 배웠습니다.
쿼리 튜닝의 첫 단계는 추측보다 실행 계획 분석이라는 원칙을 이 수업에서 몸으로 배웠습니다.
이 결의 특징
EXPLAIN 실행계획으로 먼저 병목을 짚고, 복합 인덱스와 파티셔닝을 순서대로 적용해 8초→0.5초 개선을 이끈 흔적이 보입니다. 문제를 추정하지 않고 실행계획 수치를 먼저 확인한 자리가 또렷한 결입니다.
이 결이 통하는 자리
실제 운영 DB 쿼리 튜닝 경험을 묻는 자리에서 면접관의 꼬리질문이 줄어드는 결이 보입니다. 수치 변화를 구체적으로 제시하고 개선 순서를 단계별로 짚어 신뢰를 쌓는 자리에서 자주 통합니다.