이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
MySQL을 운영하면서 가장 자주 직면한 문제는 트래픽 증가 시 슬로우 쿼리 급증이었습니다. slow_query_log를 활성화해 지연 쿼리를 수집하고, EXPLAIN으로 실행 계획을 분석해 풀 스캔이 발생하는 지점에 인덱스를 추가하면서 해결했습니다.
인덱스 과도 추가로 쓰기 성능이 저하되는 역효과도 경험했습니다. INSERT가 많은 테이블에 인덱스를 너무 많이 추가하면 쓰기 시 모든 인덱스를 업데이트하는 비용이 커졌습니다. 사용되지 않는 인덱스를 주기적으로 점검해 제거하는 것이 중요하다는 것을 배웠습니다.
레플리케이션 지연 문제도 있었습니다. 읽기를 레플리카로 분산했는데 마스터와 레플리카 간 지연이 발생해 방금 쓴 데이터가 읽기에서 보이지 않는 상황이 생겼습니다. 쓰기 직후 읽기가 필요한 경우는 마스터로 강제 라우팅하는 방식으로 해결했습니다.
MySQL 슬로우 쿼리 개선에서 수치 없이 개선했다고 말하면 실제로 얼마나 나아진지 팀에 설명이 안 됩니다. slow_query_log를 임계값 1초로 설정하니 하루 수천 건의 쿼리가 기록됐고, 그중 70%가 동일한 테이블의 3개 쿼리에서 발생하고 있었습니다. EXPLAIN으로 분석하니 복합 조건 검색에서 인덱스가 하나도 사용되지 않고 풀 스캔이 일어나고 있었습니다. 복합 인덱스를 추가하고 실행 계획을 다시 확인했습니다. 인덱스 추가 후 해당 쿼리 평균 응답 시간이 3.2초에서 80ms로 줄었습니다. 개선 수치를 팀에 공유했더니 같은 방식으로 다른 슬로우 쿼리도 정리하는 흐름이 생겼습니다.
MySQL에서 Deadlock은 재현이 어려워 로그에서 실마리를 찾아야 합니다. 간헐적으로 Deadlock found when trying to get lock 에러가 찍혔는데, 재현 조건을 만들기 어려웠습니다. SHOW ENGINE INNODB STATUS를 실행하니 마지막 발생한 Deadlock에서 두 트랜잭션이 각각 어떤 락을 잡고 무엇을 기다리는지가 기록돼 있었습니다. 원인은 두 트랜잭션이 서로 다른 순서로 두 테이블을 잠그는 것이었습니다. A는 orders → order_items 순으로, B는 반대 순서로 잡아 교착이 생겼습니다. 두 트랜잭션이 같은 순서로 테이블을 접근하도록 코드를 수정하니 Deadlock이 사라졌습니다. Deadlock은 락 순서를 통일하는 것으로 근본적으로 예방할 수 있다는 걸 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 무신사 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.