배포나 SQL 수정이 없었는데 같은 쿼리가 갑자기 느려졌습니다. 실행 계획이 바뀌었는지 어떻게 확인하고 어떤 원인을 조사하나요?

SQL이나 배포를 바꾸지 않아도 데이터 분포, 통계, 캐시된 계획, 파라미터 분포, 메모리와 잠금 상황이 바뀌면 실행 계획과 실제 비용이 달라질 수 있습니다. 먼저 느려진 요청의 SQL 텍스트·바인드 패턴·실행 시각을 확보하고, 이전 정상 계획과 현재 실제 계획을 비교하겠습니다. ‘SQL이 같으니 DB 밖의 문제’라고 넘기지 않고 추정 행 수와 실제 행 수, 논리 읽기, 메모리 grant, 정렬 spill, 대기를 함께 봅니다.

추정과 실제의 차이를 원인으로 좁힙니다

특정 고객의 주문 수가 갑자기 커졌는데 계획이 여전히 적은 결과를 예상하면, 인덱스 seek 뒤 많은 key lookup을 반복하는 방식이 작은 고객에는 빠르고 큰 고객에는 느릴 수 있습니다. 반대로 결과가 많은데 테이블 스캔이 더 싼 경우도 있습니다. 빠른 파라미터와 느린 파라미터를 같은 조건에서 실행해 계획이 공유되는지, 파라미터 스니핑·계획 캐시·통계 히스토그램의 편중을 확인하겠습니다.

통계가 오래됐다면 갱신을 검토하지만 통계 갱신이 무조건 최적 계획을 만들지는 않습니다. 갱신 직후 다른 파라미터의 계획이 바뀌거나 컴파일 비용이 생길 수 있습니다. 계획 고정·재컴파일·힌트는 즉시 완화책일 수 있지만 장기적으로 데이터 분포 변화와 다른 질의를 가릴 수 있으므로 적용 범위와 해제 기준을 정합니다. SQL Server의 Query Store와 plan forcing, PostgreSQL의 planner·통계, MySQL의 optimizer·histogram은 기능과 관찰 방식이 다르므로 같은 처방을 일반화하지 않겠습니다.

계획뿐 아니라 자원 경합을 분리합니다

계획이 같아도 버퍼 캐시 적중률 저하, 디스크 I/O, CPU 포화, 메모리 grant 부족, 동시 잠금, 복제·백업 작업으로 지연이 커질 수 있습니다. 정렬이나 hash join이 메모리에 들어가지 않아 임시 디스크로 넘치는지, 메모리 grant가 과다해 다른 요청이 대기하는지도 확인합니다. 실행 계획의 연산 비용 추정값만 믿지 않고 실제 행·읽기·spill·대기 이벤트를 함께 보겠습니다.

수정 후에는 대표 파라미터와 데이터 편중, 콜드·웜 캐시, 동시 부하를 비교합니다. 한 고객만 빨라지고 큰 고객의 p99가 악화되면 완료로 보지 않습니다. 계획 이력은 모든 요청을 무제한 수집하기보다 상위 지연·계획 변경·오류 사례를 샘플링해 운영 부담을 관리합니다. 성공 기준은 현재 계획이 예뻐 보이는 것이 아니라 입력 분포가 바뀌어도 서비스의 읽기·CPU·메모리·지연 예산 안에 머무는 것입니다.

계획 비교에서는 estimated cost 숫자 하나보다 실제 실행 시간의 구성과 계획 선택의 안정성을 봅니다. 통계 갱신·인덱스 변경·파라미터 분포가 바뀐 시각과 회귀가 시작된 시각을 맞춰 원인을 좁히고, 동시 실행으로 인한 잠금·메모리 대기를 계획 회귀와 분리합니다. plan forcing을 사용한다면 통계와 데이터가 다시 변했을 때 자동으로 재평가할 경보와 해제 조건을 둬 오래된 계획을 영구 고정하지 않겠습니다.