데이터베이스 인덱스 없이 쿼리가 느려질 때

데이터베이스 인덱스 문제는 검색해서 들어온 상황이라면 바로 재현 조건부터 잡는 게 빠르다. 작은 이상 신호도 빨리 분리해서 봐야 한다.

핵심은 한 가지만 붙잡지 않고 데이터 계층 전체 흐름에서 원인을 좁히는 것이다. 재현 조건, 로그, 응답처럼 눈으로 확인할 수 있는 값들을 먼저 모아야 한다.

첫 번째 확인: 스키마 검증

Prisma를 사용한다면 스키마부터 검증해야 한다. 인덱스가 제대로 정의되었는지 확인한다.

npx prisma validate
npx prisma migrate status

validate로 스키마 문법 에러를 찾는다. migrate status로 적용되지 않은 마이그레이션이 있는지 본다.

두 번째 확인: 데이터베이스 연결

DATABASE_URL이 제대로 설정되었는지 확인한다. 특히 프로덕션과 로컬의 데이터베이스가 다르다면, 로컬에는 있지만 프로덕션에는 없는 인덱스가 있을 수 있다.

쿼리 성능 측정

느리다는 것이 정확히 어느 정도인지 측정해야 한다. 밀리초 단위로 쿼리 시간을 기록한다.

같은 쿼리를 여러 번 실행했을 때 시간이 일정한지 본다. 캐시 때문에 첫 번째는 느리고 두 번째부터는 빠르다면, 인덱스가 없는 것일 가능성이 높다.

브라우저에서 볼 수 있는 값

데이터를 표시하는 화면에서 로딩 시간이 얼마나 걸리는지 확인한다. 개발자 도구의 Network 탭에서 API 응답 시간을 본다.

백업과 인덱스 확인

마이그레이션을 실행했다고 해서 인덱스가 제대로 생성되었는지 보장할 수 없다. 데이터베이스 클라이언트 도구로 직접 확인한다.

실수하기 쉬운 부분

1. 로컬 데이터베이스와 프로덕션 데이터베이스가 다른 스키마를 가질 수 있다
2. 마이그레이션이 실행 대기 중이지만 아직 적용되지 않았을 수 있다
3. 인덱스는 정의했지만 데이터가 너무 많아서 효과가 없을 수도 있다

체크리스트

1. 원래 증상이 같은 조건에서 다시 나는지 확인한다
2. 로그에서 바뀐 부분을 한 줄로 설명해본다
3. npx prisma validate와 migrate status로 스키마를 확인한다
4. 데이터베이스 클라이언트로 인덱스를 직접 본다
5. 쿼리 성능을 밀리초 단위로 측정한다

해결 자체보다 어떤 값이 달라졌는지 설명할 수 있는 상태가 더 중요하다. 관련 기록을 짧게라도 남겨두면 다음 확인이 훨씬 빨라진다.