이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
MySQL을 처음 운영 수준으로 사용한 것은 팀 프로젝트에서 직접 서버를 세팅하고 데이터를 관리하면서였습니다. 단순 ORM 사용에서 벗어나 스키마 설계와 인덱스 전략을 직접 결정하는 경험을 했습니다. 슬로우 쿼리 로그를 활성화해 응답이 느린 쿼리를 추적했는데, 조인이 많은 쿼리에서 인덱스가 없는 컬럼을 WHERE 조건으로 쓰는 것이 원인인 경우가 많았습니다.
EXPLAIN으로 실행 계획을 확인하는 습관을 들였고, Full Table Scan이 나오면 인덱스를 추가하거나 쿼리를 재작성하는 방식으로 개선했습니다. 백업 전략도 중요하게 생각했는데, mysqldump로 주기적인 스냅샷을 만들고 별도 스토리지에 보관하는 방식을 구성했습니다. 한계는 데이터가 수백만 건 이상이 되면 현재 방식의 한계를 직접 경험하지 못했다는 점입니다. MySQL 운영은 읽기 패턴에 맞는 인덱스 설계가 성능의 결임을 배웠습니다.
MySQL 운영에서 슬로우 쿼리 로그를 처음 활성화해보고 운영 환경의 실상을 처음 본 경험이 있습니다. 개발 중엔 문제없던 쿼리가 데이터가 쌓이면서 슬로우 쿼리로 잡히기 시작했습니다.
slow_query_log와 long_query_time을 설정해 로그를 모으고, EXPLAIN으로 실행 계획을 확인해 풀스캔이 보이는 쿼리를 먼저 개선했습니다. JOIN 순서를 바꾸고 커버링 인덱스를 추가하니 평균 쿼리 시간이 절반 이하로 줄었습니다.
이 경험으로 MySQL 운영은 쿼리를 한 번 잘 짜는 것으로 끝나지 않고, 데이터 규모에 따라 지속적으로 살펴야 한다는 걸 배웠습니다.
MySQL 운영에서 커넥션 수가 급증해 서버가 응답을 거부하는 상황을 경험했습니다. 서비스 트래픽이 특정 시간대에 몰리면서 max_connections 한계를 초과하는 에러가 잇달아 발생했습니다.
원인을 보니 쿼리 처리 시간이 길어서 커넥션이 반환되지 않고 쌓이는 구조였습니다. 쿼리 최적화로 처리 시간을 줄이고, 앱 쪽에서 커넥션 풀을 설정해 커넥션 재사용 비율을 높였습니다. 피크 시간대 에러율이 0에 가까워졌습니다.
이 경험으로 DB 운영 문제는 DB 설정만의 문제가 아니라 쿼리·앱·인프라 세 계층에서 함께 봐야 한다는 걸 배웠습니다. 장애는 항상 한 계층에서만 오지 않았습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 핀다 DBA 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.