오늘도 한결같이 회사업무를 보는중

특정 데이터 조회시 유독 시간이 엄청나게 소요되는 현상이 발견되었다.

세상에!

응답시간이 무려 9.6초가 나왔다.

그리드특성상 페이징처리를 따로 안한다고 해도,
전체 데이터 양이 적은양은 아니라고 해도

이건 뭔가 이상하다...

실제 DB에서 호출된 쿼리를 실행된 결과를 보니

682개의 row를 조회하는데 걸린 시간이 무려
9.368초

아무리 서브쿼리가 많다고 해도,
조인절이 많다고 해도 뭔가 이상하다.

---

아마 이 글을 읽고있는 대부분의 독자분들이 바로 생각 할
그 생각이 났다.


'이거 인덱스 제대로 못타고있다.'

이제 9개월된 초보개발자. 솔직하게

인덱스가 어쩌구 저쩌구... 잘 모르겠다..
내가 아는건
단지 PK, FK 지정시 클러스터드 인덱스가 생성이 되고
대부분 RDB는 B-tree, B+tree를 이용한다. 정도....

카더널리가 높고, 선택률이 낮고... 거기까진 모르겠다.
(책에서 한번 읽긴 했는데 다시 공부해서 한번 포스팅 해보면 재밌겠다는 생각이 든다.)

처음에는 PK값이 두개, 세개면 인덱스 성능이 떨어지나?
역시 id라는 필드를 한개 설정해주는게 확실히 좋은가?
PK가 설마 없나?
그런 생각을 하면서도 우선

조인절, 서브쿼리나 사용자정의함수에 들어가는 테이블을 전부 다 찾아서
인덱스 여부를 파악했으며 마침내 인덱스가 걸려있지 않은 한개의 테이블을 찾았다.

다행히 PK가 설정되어 있지 않은 테이블을 발견하였고.

PK를 넣어주었다.
PK가 생성됨과 동시에 인덱스가 만들어졌다.

두근두근 다시한번 조회성능을 확인할 차례...

(이쯤 삽질하고 있으니 회사 선배도 얼마나 빨라지는지 구경하기 시작했다.)

와 속도 실화냐??
9.6초 걸리던 호출이 0.9초로 줄었다.

아까 DB에서 직접 날리던 쿼리의 속도는 얼마나 줄어들었을까?

(대충 진짜 인덱스는 진짜 전설이다... 가슴이 웅장해진다.. 내가알던 그 인덱스가 맞냐?.. 뭐 그런내용...)

---

결론(?)

단순히 인덱스 하나만으로 조회속도가 10배가량 증가한 모습을 볼 수 있었다.

결국 원본이터가 몇개든 700개 살짝 안되는 데이터접근에 1000ms면 아직도 길다고 느낄 수 도 있을것이고,
쿼리나 다른쪽으로 성능개선의 여지는 많이 남아있겠지만

'인덱스를 사용하면 엄~청 빠르다. I/O가 많은곳에서는 안좋을수도 있다.' 이런 얘기들을 책에서만 보다가
직접 업무를 통해서 직접 조회속도를 1/10으로 줄여보는 경험자체가 참 신기하고 와닿았다.

역시 개발자는 직접 코드로 구현을 해봐야 이해도 잘되고 재밌다.

앞으로도 업무에 최선을 다하면서
이런 책에서 봤던 내용을 계속 적용할 수 있었으면 좋겠다.
재밌었다. ^ᴗ^