NestJS 성능과 확장

데이터베이스 쿼리 최적화: EXPLAIN과 index 점검

쿼리 최적화는 ORM 코드를 짧게 만드는 일이 아닙니다. 실행 계획과 데이터 분포, 인덱스 선택도, 트랜잭션 범위를 같이 확인합니다.

느린 쿼리는 endpoint, SQL, 실행 계획, 배포 지표를 한 줄로 묶어 추적한다

작은 fixture의 성공보다 운영 데이터에서 줄어드는 row와 lock 시간을 확인한다.

endpoint 느린 API와 request 조건을 고정하고 같은 데이터 크기로 비교한다.
EXPLAIN index hit, rows, filtered, filesort, lock wait 신호를 읽는다.
migration index 순서와 write cost를 migration diff에서 같이 검토한다.
metric p95/p99, slow log, lock wait가 배포 전후로 줄었는지 남긴다.
01

EXPLAIN 실행 계획과 index 선택도

WHERE, JOIN, ORDER BY 컬럼의 index 사용 여부와 row estimate가 실제 데이터 분포와 맞는지 봅니다.

실행 계획
02

Repository query와 index migration

ORM query builder, relation loading, cursor pagination, index migration을 같은 use case 단위로 묶습니다.

query 경계
03

Full scan과 N+1

작은 fixture에서는 빠른 쿼리도 운영 데이터에서 full scan, filesort, lock wait, N+1로 바뀔 수 있습니다.

병목 재현
04

Slow query log와 percentile

EXPLAIN diff, p95/p99 query time, index hit ratio, slow query log를 배포 전후로 남깁니다.

DB 지표
책임
쿼리 최적화는 EXPLAIN 실행 계획과 실제 데이터 분포를 함께 본다 DB index가 선택되는지, scanned rows와 filtered 비율이 예상과 맞는지 endpoint별로 확인합니다.
계획
경계
repository method는 pagination과 relation loading 비용을 드러내야 한다 select 컬럼, join, eager/lazy loading, cursor 조건을 code review와 migration diff에서 같이 추적합니다.
query
인덱스 비용
index migration은 slow query log와 배포 후 percentile로 검증한다 새 index가 write cost를 키우지 않는지 p95 query time, lock wait, deadlock 로그를 함께 봅니다.
index

DB index와 EXPLAIN 실행 계획 검증 지점

EXPLAIN index hit repository query, EXPLAIN 실행 계획, index 사용 여부, p95 query time이 같은 endpoint 기준으로 줄어드는지 확인합니다.
운영 병목 패턴 작은 데이터만 보면 full scan, N+1, lock wait가 숨어 배포 뒤 connection pool 고갈로 드러날 수 있습니다.
Slow query 지표 slow query log, EXPLAIN diff, index migration, p95/p99 query time을 배포 전후로 비교합니다.

DB query 점검

질문: EXPLAIN 실행 계획이 index 사용과 row estimate를 보여주고 p95 query time이 줄었는가
순서: slow query 선택 -> index migration 준비 -> EXPLAIN diff와 percentile 비교
위험: 작은 fixture만 보면 N+1과 full scan이 숨어 배포 뒤 DB connection pool이 먼저 고갈됩니다.