데이터베이스 와 SQL 에 대해서 너무 지식이 부족하여서 이번 기회에 공부를 제대로 해보려고 합니다.
먼저 그 생각을 가지게 된 계기인 인라인뷰에 대해서 공부해보려고 합니다.

인라인뷰

서브쿼리의 일종으로 서브쿼리가 FROM 절에서 안에서 사용하는 경우, 해당 서브쿼리를 '인라인뷰'라고 합니다.

서브쿼리의 결과가 하나의 테이블에 대한 View 처럼 사용된다고 해서 인라인뷰라고 합니다.

SELECT  member.mb_id, 
        member.address  
FROM  (SELECT * FROM member_table) AS member

위에 쿼리문은 의미없는 인라인뷰 쿼리문이긴 한데 이런식으로 FROM 절 안에 쓰이는 서브쿼리가 바로 인라인뷰 입니다.

말만 거창하지 별거 없습니다.

그렇다면 이 인라인뷰를 굳이 왜 쓸까요?
그냥 성능적으로 좋은 Join걸면 되는데?

왜 서브쿼리는 성능적으로 안좋을까요?
서브쿼리는 결과 건수만큼 반복 수행되기 때문에 조회되는 데이터의 갯수가 적다면 크게 문제될 것은 없지만, 조회 결과의 데이터의 갯수가 많아지면 성능이 현저히 떨어지는 모습을 볼 수 있습니다.

성능따지다 지쳐 죽은 개발자

성능적으로 무조건 좋은게 좋은걸까요?
물론 성능이 좋으면 좋죠 하지만 100% 모든 경우가 그런 것은 아닙니다.

성능만 따지면서 개발을 진행하다가 개발이 어려워져 지쳐 힘들어지는 상황이 생기는 수가 있습니다.

개발이란 것은 사람이 하기 때문에 개발하기 편해야 하고 유지보수 하기가 편해야합니다.
개발자가 직관적이지 않고 몇십 몇백줄이 되는 하나의 쿼리문을 쉽게 변경할 수 있을까요?
(개발자도 사람이야 사람!!)

서브쿼리는 성능적으로 JOIN보다 안좋습니다.
하지만 밑에와 같은 장점들을 가지고 있습니다.

• 쿼리를 더 간결하고 읽기 쉽게 만들 수 있습니다.
• 쿼리의 복잡성을 줄일 수 있습니다.
• 쿼리의 결과를 필터링하거나 정렬할 수 있습니다.
• 쿼리의 성능을 향상시킬 수 있습니다.

위에 장점들은 개발자에게 개발하기 편한 환경을 제공해 줄 수 있습니다.

쿼리의 가독성 측면에서 장점을 제공해주는 건 이해했는데
서브쿼리로 쿼리의 성능을 향상시키는게 가능한걸까요???

대표적인 예시인 인라인뷰를 활용한 페이징 처리를 알아보러 갑시다.

인라인뷰를 활용한 페이징

# MySQL 기반 쿼리문 입니다.

# 그냥 페이징 처리하는 쿼리문
SELECT *
FROM board
ORDER BY create_at DESC
LIMIT 10, 10;

# 인라인뷰를 활용한 페이징 처리하는 쿼리문
SELECT *
FROM (
    SELECT *
    FROM board
    ORDER BY create_at DESC
) AS inline_view
LIMIT 10, 10;

일반적인 페이징 처리하는 쿼리문은 조회 방식은 10개의 데이터를 가져오고 그 이후 필요한 10개의 데이터를 추가로 가져온다음에 필요없는 이전 10개의 데이터를 버리는 형식으로 조회를 합니다.
총 20개의 데이터를 조회하게 되겠죠?

OFFSET이 10이라 그렇게 안커보이지 만약 3,000,000개 라면? 3,000,010개의 조회를 하게 되는 것입니다........ 진짜 최악이죠.

인라인뷰를 활용하여 페이징 처리하는 것은 일반적인 페이징 처리하는 쿼리문보다 성능이 좋습니다. 인라인뷰를 사용하면 저희가 원하는 데이터만 조회하여 데이터 10개를 조회합니다.

왜 이렇게 되는지 실행계획을 한번 살펴 볼까요?

일반적인 페이징은 type이 ALL로 모든 데이터를 조회하는 것을 알 수 있습니다.
그렇기 떄문에 모든 데이터를 조회한 이후에 필요없는 데이터를 전부 버리는 방식으로 얻게 되는 것입니다.

인라인뷰를 활용한 페이징은 type이 RANGE로 일부분만 조회하는 것을 확인할 수 있습니다.
그렇기 때문에 저희가 원하는 부분에 대해서만 데이터를 얻어 10개만 조회를 하는 것입니다.

주의사항

여기서 중요한 것인 페이징 처리 방식 이라던지 실행계획은 DBMS 마다 전부 다르니
자기가 어떠한 DBMS를 쓰는지 확인하고 거기에 맞는 쿼리문을 작성하면 될 것 같습니다.
또한 페이징처리는 인라인뷰 말고도 NoOffset 방식, 커버링인덱스 방식 등이 있으니 원하는 방식을 적용하면 될 것 같네요.

느낀 점

인라인뷰 뿐만 아니라 스칼라 서브쿼리도 비슷한 맥락으로 많이 작성을 한다는 것도 알았는데 글을 쓸떼는 스킵하였습니다.

서브쿼리도 참 중요하구나 라고 생각이 들었고 개발하기 편한 쪽으로 생각을 계속 해봐야겠구나 라고 생각이 드네요.
실행계획을 확인하면서 쿼리문 튜닝하는 식으로 개선해나가는 습관을 들이려고 합니다.
특히나 페이징 처리는 성능이 어느정도는 중요하긴 해서 내부적으로 어떻게 동작하는지 잘 알아야 할 것 같습니다.