Quiz: Query Tuning and Execution Plans

실행계획의 cost 값에 대한 올바른 이해는?

• 밀리초 단위의 예상 실행 시간이라 값이 곧 소요 시간을 뜻한다
• 페이지 순차 읽기를 1.0 으로 둔 상대 점수라 절대 기준으로 위험을 판단할 수 없다
• 옵티마이저가 실제로 읽기로 결정한 행 수를 나타내는 값이다
• 쿼리 수행에 필요한 작업 메모리를 메가바이트 단위로 추정한 값이다

실행계획에서 예측 행 수는 1 인데 실제 행 수가 480,000 이었습니다. 가장 먼저 할 일은?

• 원하는 계획이 나오도록 쿼리에 조인·인덱스 힌트를 붙인다
• 옵티마이저를 헷갈리게 하는 인덱스를 지워 선택지를 줄인다
• 통계를 갱신한다 — 옵티마이저가 잘못된 전제 위에서 계산한 것이다
• 행 수가 많으니 테이블을 파티션으로 나눠 스캔 범위를 줄인다

실행계획에서 Hash Join 이 131ms, 그 자식인 Seq Scan 이 92ms 로 나왔습니다. 조인 자체가 소비한 시간은?

• 131ms — 노드에 적힌 시간이 그 노드의 작업 시간이다
• 약 39ms 이하 — 부모 시간은 자식을 포함한 누적값이기 때문
• 223ms — 부모와 자식의 시간을 더해야 전체가 된다
• 92ms — 실제 데이터를 읽은 자식 노드가 곧 조인 비용이다

WHERE substr(ORD_DT,1,6) = '202608' 이 인덱스를 타지 못하는 이유는?

• substr 호출이 행마다 일어나 인덱스 탐색보다 비용이 커지기 때문
• 문자열 비교는 정렬 규칙이 개입해 인덱스 순서를 쓸 수 없기 때문
• 인덱스는 컬럼의 원래 값으로 정렬돼 있는데 함수를 씌우면 그 순서를 못 쓰기 때문
• 옵티마이저가 함수가 든 조건을 상수로 접지 못하는 알려진 한계 때문

실행계획에 Seq Scan(전체 스캔)이 보일 때의 올바른 태도는?

• 전체 스캔은 대량 읽기를 뜻하므로 해당 조건에 인덱스를 만들어야 한다
• 옵티마이저가 인덱스를 못 쓸 형태라는 신호이므로 쿼리를 다시 쓴다
• 테이블이 작거나 대부분의 행을 읽는 쿼리라면 최선일 수 있으므로 상황을 본다
• 통계가 낡아 잘못 고른 계획이므로 먼저 통계를 갱신하고 다시 본다

N+1 문제가 로그만 봐서는 발견하기 어려운 이유는?

• ORM 이 내부에서 만든 쿼리는 애플리케이션 로그에 남지 않기 때문
• 지연 로딩으로 나간 쿼리는 별도 스레드에서 실행돼 로그가 흩어지기 때문
• 쿼리 하나하나는 빨라 문제로 안 보이는데, 왕복 횟수가 데이터 양에 비례해 늘기 때문
• N+1 은 실행계획에만 드러나고 쿼리 로그에는 흔적이 남지 않기 때문

데이터 이관 직후 성능이 갑자기 나빠졌다는 신고의 흔한 원인은?

• 통계 미갱신 — 쿼리와 인덱스는 그대로인데 낡은 통계로 계획이 어긋난 것
• 이관 트래픽이 회선을 채워 응용 요청까지 밀린 것
• 대량 삽입으로 파일이 조각나 순차 읽기가 느려진 것
• 이관 도구가 커넥션을 물고 있어 풀에 여유가 없어진 것