DB 인덱스 문제 빠르게 찾는 방법

데이터베이스 문제는 화면에는 드러나지 않지만 로그와 실행 계획에서 명확하게 나타난다. 로컬에서는 잘 돌던 쿼리가 프로덕션 데이터셋에서 느려지는 경우가 많은데, 이때 스키마와 인덱스를 먼저 확인해야 한다.

먼저 스키마 상태 확인

마이그레이션이 모두 적용됐는지, 스키마가 일치하는지 확인한다. Prisma를 쓰면 간단하게 검증할 수 있다.

npx prisma validate
npx prisma migrate status

마이그레이션 상태에서 Pending migration이 있으면 프로덕션과 로컬 환경의 스키마가 다르다는 뜻이다. 이 상태에서는 같은 코드도 다르게 동작한다.

데이터베이스 연결 상태 확인

환경 변수가 제대로 설정되었는지, 데이터베이스 호스트에 접근할 수 있는지 확인한다.

# DATABASE_URL 확인
echo $DATABASE_URL

# 직접 연결 시도 (PostgreSQL 기준)
psql "$DATABASE_URL" -c "SELECT version();"

연결 풀이 부족하거나 타임아웃이 발생하면 로그에 명확하게 나타난다.

인덱스 상태 확인

인덱스 누락이나 중복은 성능에 직접적인 영향을 미친다. 실제 데이터베이스에 만들어진 인덱스 목록을 확인한다.

# PostgreSQL에서 인덱스 목록 확인
psql "$DATABASE_URL" -c "SELECT * FROM pg_indexes WHERE schemaname='public';"

마이그레이션 파일에는 있지만 실제 테이블에는 없는 인덱스가 있을 수 있다. 롤백이나 실패한 마이그레이션 때문이다.

쿼리 실행 계획 분석

느린 쿼리가 인덱스를 제대로 사용하는지 확인한다.

psql "$DATABASE_URL" -c "EXPLAIN ANALYZE SELECT ... FROM ...;"

실행 계획에서 Seq Scan (풀 테이블 스캔)이 나타나면 인덱스가 없거나 옵티마이저가 인덱스를 사용하지 않는 것이다. Index Scan이 나타나면 인덱스가 제대로 작동하는 상태다.

백업과 복구

데이터 손상이 의심되면 최근 백업본과 비교한다. 개발 환경과 프로덕션 환경의 데이터가 다를 수 있으니 프로덕션 백업부터 확인해야 한다.

1. 마지막 성공한 백업의 생성 시각 확인
2. 현재 데이터베이스의 row count 비교
3. 의심되는 테이블의 데이터 무결성 점검

로그 기록 남기기

나중에 비슷한 문제가 생기면 빠르게 대응하려면 지금 확인한 값들을 기록해야 한다. 현재 마이그레이션 버전, 인덱스 목록, 실행 계획 결과를 저장해두면 다음 문제 해결 시 비교할 기준점이 된다.