https://gukin.dev/tags/mysql/ Recent content in Mysql on Gukin Han Hugo ko-kr Sat, 13 Dec 2025 00:00:00 +0000 https://gukin.dev/posts/correlated-subquery-read-bottleneck/ Sat, 13 Dec 2025 00:00:00 +0000 https://gukin.dev/posts/correlated-subquery-read-bottleneck/ <h2 id="요약">요약</h2> <ul> <li>문제 <ul> <li>운영 환경에서 조회 API 응답 지연(1초 이상) 이슈 발생</li> <li><strong>상관 서브쿼리로 인한 N+1 패턴</strong>이 DB 레벨에서 발생</li> </ul> </li> <li>과정 <ul> <li>실행 계획 분석을 통해 Nested Loop 반복 실행과 <strong>옵티마이저 통계 오류</strong>를 확인</li> <li>상관 서브쿼리를 <strong>CTE + Hash Join</strong> 구조로 리팩토링</li> </ul> </li> <li>성과 <ul> <li>서브쿼리 실행 <strong>92회에서 1회로 감소</strong></li> <li>총 실행 비용 <strong>246.0에서 40.6로 감소</strong> (약 83% 개선, 6배 성능 향상)</li> <li>운영 데이터 기준으로 실행 계획 변화와 성능 개선을 수치로 검증</li> </ul> </li> </ul> <h2 id="문제-배경">문제 배경</h2> <p>운영 중인 서비스에서 특정 테넌트 기준 조회 API의 응답지연이 보고되었다. 슬로우 쿼리 분석 결과, 직원을 그룹화하는 테이블의 조회 쿼리 내부에 상관 서브쿼리(Correleated Subquery)가 포함되어있었다. 그 영향으로 메인 쿼리 결과 행 수만큼 서브쿼리가 반복 실행되는 문제가 발생했다.</p> https://gukin.dev/posts/read-heavy-pagination-optimization/ Fri, 15 Aug 2025 00:00:00 +0000 https://gukin.dev/posts/read-heavy-pagination-optimization/ <h2 id="요약">요약</h2> <ul> <li><strong>정규화 쿼리(집계 + 정렬)</strong> → 풀스캔 + filesort로 <strong>~17초</strong> 소요.</li> <li><strong>역정규화 + 정렬 포함 인덱스</strong> → <strong>~227ms</strong> (약 76배 향상).</li> <li><strong>OFFSET 페이지네이션</strong> → 인덱스 순차 스캔 시작 → 임계점에서 Table Scan + Filesort로 전환 → 이후 응답시간 급등.</li> <li><strong>전환 전 일정한 속도</strong>는 InnoDB 버퍼 풀/캐시 히트율 덕분.</li> <li><strong>Keyset(Seek) 페이지네이션</strong> → 깊은 페이지에서도 일정 성능 (421ms → 31ms, 92.6% 단축).</li> <li><strong>인덱스 설계</strong>는 핫 트래픽 패턴(브랜드 + 인기순/최신순/최저가순)에 맞춘 3개의 복합 인덱스 유지가 가성비 최적. <ul> <li>설계 원칙: 필터 선두 → 정렬키 → tie-breaker(id)</li> </ul> </li> <li><strong>캐시(Cache-Aside)</strong> 적용 시 200RPS에서도 DB I/O 부하 없이 ms 단위 응답 가능. <ul> <li>단, TTL·Evict 정책·실시간성 요구사항·정합성 유지·스탬피드 방지 등 고려 필수.</li> </ul> </li> <li>결론: <strong>정규화/역정규화 → 인덱스 설계 → 페이지네이션 전략 → 캐싱</strong>이 단계적으로 맞물려 성능을 좌우함.</li> </ul> <h2 id="문제-정의와-가설">문제 정의와 가설</h2> <p>웹 서비스에서는 쓰기 보다 <strong>읽기 트래픽이 압도적으로 많다</strong>는 글을 읽거나 실제로 경험해봤을 것이다.</p> https://gukin.dev/posts/innodb-lock-conflict-deadlock-analysis/ Fri, 08 Aug 2025 00:00:00 +0000 https://gukin.dev/posts/innodb-lock-conflict-deadlock-analysis/ <h2 id="요약">요약</h2> <ul> <li>MVVC는 트랜잭션 시작점을 기준으로 <strong>데이터 버저닝</strong>을 한다</li> <li>락 종류에 따라 <strong>충돌 상황을 테스트</strong> <ul> <li>공유락은 말그대로 트랜잭션끼리 공유할 수 있다</li> <li>베타락은 말그대로 하나의 트랜잭션만 가진다</li> <li>공유락을 가진 상태로 업데이트, 삭제 등을 하면 베타락을 획득하려는 시도를 한다</li> <li>락 획득 대기 사이클이 생기면 데드락이 발생한다</li> </ul> </li> <li><strong>데드락을 최소화</strong>하기 위한 락 설계 방법: <ul> <li>락을 잡는 순서를 트랜잭션 마다 동일하게 유지</li> <li>락 범위를 축소</li> <li>첫 쿼리 부터 for update로 가져오는 방법</li> </ul> </li> </ul> <h2 id="배경">배경</h2> <p>이번 주차는 낙관적 락과 비관적 락을 학습하게 되었다. 비관적 락은 흔히 느리지만 정합성이 중요할때 사용하며, 낙관적 락은 충돌 가능성이 낮을 때 상대적으로 빠른 상황을 요구할때 사용한다고 한다.</p> https://gukin.dev/posts/delete-insert-innodb-deadlock/ Mon, 21 Apr 2025 00:00:00 +0000 https://gukin.dev/posts/delete-insert-innodb-deadlock/ <h2 id="배경">배경</h2> <ul> <li>최근 우리 서비스는 Sentry를 통해 데드락 알람을 자주 받고 있다</li> <li>처음에는 중복 인덱스를 발견해서 제거하는 작업을 진행했다 <ul> <li>그럼에도 불구하고 동일한 로직에서 데드락이 발생하는 중이다</li> <li>조금은 빈도가 감소했을 수 있는데, 데드락 모니터링과 수집 및 통계화를 다른 회사에서는 어떻게 하는지 리서치가 필요해 보인다</li> </ul> </li> <li>아무튼 데드락을 분석해보니, 동일한 레코드의 DELETE-INSERT가 하나의 트랜잭션 내 수행되는 API에서 발생하였다</li> <li>명확한 원인을 파악하고 전략을 세우기 위해 분석을 시도하였다</li> </ul> <h2 id="innodb-deadlock-분석">InnoDB Deadlock 분석</h2> <h3 id="innodb-엔진-내부-상태를-확인하는-방법">InnoDB 엔진 내부 상태를 확인하는 방법</h3> <p>RDMBS 클라이언트에서 위 명령어를 입력:</p>