[mysql] view의 장단점, 성능에 대한 고찰

발단

회사에서 포스트맨을 확인하고 로컬로 각 api들을 돌려보는데.. 게시글을 조회, 검색하는 로직에서 너무 오래걸리는 것을 확인했다. 그냥 단순한 게시판인데 값을 가져오는데 평균 1200~2000ms정도가 소요되었다. 

 

아무리 생각해도 이상하다. 코드를 확인했더니 서비스 로직에서 직접 sql문을 사용하여 쿼리를 넣고 있었다. SQL을 봐도 간단하게 SELECT ~~~ FROM view_~~~ 이런식으로 되어있는데 오래걸릴 수가 있나? 파일을 보내는 것도 아니고 단순 json인데.. 

 

의심해볼 수 있는 것은 view다. 회사코드를 공개할 수는 없지만, view의 장단점과 성능저하가 왜 일어났는지 포스팅하려 한다. 

결론적으로 view 대신 다 뜯어내고 join했을 때 1200~2000ms에서 5~40ms로 성능을 개선했다. 

 

view의 특징, 장단점 순으로 확인해보자. 

뷰의 특징

- 뷰는 쉽게 정리하면 가상의 테이블이다.

데이터를 실제로 저장하고 있지는 않고, 미리 db에서 세팅하여 마치 기존 테이블처럼 가져올 수 있는 것이다.

그렇지만 앞서 말한 것처럼 데이터를 실제로 저장하는 것은 아니기에 쿼리문이 실행되었을 때 가상의 테이블이 생성되면서 가져온다고 보면 되겠다. 

뷰의 장점

- 복잡한 쿼리의 단순화

미리 여러 테이블을 합친다거나 변경해놓으면 준비해놓은 가상의 테이블을 SELECT만 하면 바로 가져올 수 있다. 사실 미리 준비하는 상황에서 복잡할테니 조삼모사긴 하다..

 

- 쿼리의 재사용

위에서 말한 복잡한 쿼리를 한 번 db에 세팅해놓으면 그대로 가져다가 쓰면 되기 때문에 같은 합쳐진 데이터를 사용할 경우 재사용할 수 있다. 그렇기에 코드의 가독성 또한 훨씬 좋아진다. 

 

예를 들어보면,

기본적으로 회원가입을 할 때 이메일, 닉네임, 패스워드, 생년월일을 저장한다고 생각해보자. 

필수로 알아야 하는 정보가 저렇게 되지만, 추후 회원정보를 업데이트할 때 휴대폰번호나 프로필사진 등 추가되는 데이터나 혹은 게시물처럼 직접적인 연관성은 없지만 매핑이 필요한 데이터가 있을 수 있다. 

 

이 때 게시물을 조회하려면 최소한 닉네임, 프로필사진, 게시물 정보 등이 필요할텐데 뷰를 통해서 미리 일부 컬럼을 join해서 필요한 정보만 정리를 해놓고, 만든 가상의 테이블을 crud안에서 그대로 가져와서 쓸 수 있으니 편하기도 하고 가독성도 좋을 수 있다. 

뷰의 단점

- 한번 세팅한 뷰는 변경할 수 없다. 

- 큰 테이블 혹은 복잡한 로직의 경우 성능저하

- insert, update, delete등 변동사항에 있어서 제한이 있음. 

 

이 중에서 내가 오늘 포스팅을 하는 것은 성능저하에 관련된 부분이다. 

 

맨 앞에서 언급했듯 게시판에 접속했는데 전체 게시물을 조회하는데 체감상 3초는 걸린 것 같다. 개발단계라 저장된 게시글이 많지도 않다. 약 3개정도인데..... 

 

어떻게 view를 갖췄는지 확인했는데, 회원, 회원등급, 게시글, 댓글, 대댓글, 이미지 등을 join하고 게시글별로 json으로 묶어서 처리하고 있었다. 

그리고 회원, 회원등급에 대해서도 다른 view가 형성되서 view가 약 3중으로 중첩되어 있었다. 

 

이를 각각 풀어내서 LEFT JOIN으로 하나씩 SELECT해줬더니 1200ms가 걸리던게...10ms도 걸리지 않았다. 그럼 그렇지 아무리 생각해도 오래걸릴게 아니였다. 

 

 

코멘트

뷰는 성능에 영향을 미치지 않을 정도로 단순한 일대일 매핑을 하는 용도로만 사용하면 좋을 것 같다.