[실습] 인덱스 직접 설정해보기/성능 측정해보기

4 asked

0

안녕하세요 dongdong2님! 강의 잘 봐주셔서 감사합니다ㅎㅎ

정확히는 인덱스가 영향을 주는 건 execution 구간입니다. 여기는 110ms → 7~11ms로 이미 10배 이상 깔끔하게 줄었어요. 실습에서 확인하려던 효과는 완벽하게 나온 겁니다.

그럼 510ms 스파이크의 정체는 뭘까요 ?

튄 부분을 보면 execution이 아니라 fetching(499ms) 입니다. fetching은 1,028행을 DB에서 클라이언트(DataGrip/DBeaver 등)로 전송하고 그리드에 렌더링하는 시간이에요. 인덱스와는 무관한 구간이고, 네트워크 상태·JVM GC·클라이언트 UI 렌더링 등에 따라 수백 ms씩 흔들립니다.

즉 "인덱스가 아직 캐싱 안 돼서"라는 설명은 방향이 살짝 다릅니다. 그 논리라면 execution이 튀어야 하는데, 첫 실행부터 이미 11ms였거든요.

정리하자면 크게 신경 쓰지 않으셔도 되는 정도의 오차입니다.

이 외로 또 궁금하신 점 있으시면 편하게 질문 남겨주세요~~

0

안녕하세요, 인프런 AI 인턴입니다. dongdong2님.

인덱스 생성 후 쿼리를 처음 실행할 때 시간이 더 소요되는 현상에 대해 설명드리겠습니다. 이와 같은 현상은 데이터베이스에서 흔히 발생하는 “캐시 효과” 때문입니다. 즉, 데이터베이스 시스템은 쿼리 결과에 필요한 데이터를 캐시에 저장하여, 이후 동일한 쿼리가 실행될 경우 더 빠르게 처리할 수 있도록 합니다. 처음 인덱스를 사용하여 쿼리를 실행했을 때 캐시되지 않은 데이터들이 있어 시간이 더 소요된 것입니다.

캐시가 초기화되거나, 데이터베이스가 처음 작동해 메모리에 데이터가 아직 로드되지 않은 경우 이러한 현상이 발생할 수 있습니다. 그러나 이후 실행에 있어서는 쿼리 성능이 향상된 것을 볼 수 있습니다. 이러한 초기 캐시 미스 현상은 성능 측정에서 지배적인 요인으로 작용하지 않으므로 크게 신경쓰지 않으셔도 됩니다.

관련해서 비슷한 상황 및 추가 정보에 대해 알고 싶으시면, 아래 유사한 질문을 참고하세요:

• 질문이있습니다.: EXPLAIN과 실제 성능 결과 차이에 대한 논의가 있습니다.
  

이러한 캐시의 초기 현상은 정상적인 과정이며, 결과적으로 인덱스를 생성하여 성능이 개선된 모습에서 알 수 있듯이 올바른 방향으로 성능 최적화를 해주셨습니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.