반응형

데이터가 많아질수록 해당 데이터를 검색해서 출력해주는 퍼포먼스가 중요합니다.

같은 내용을 가져오더라도, 쿼리를 어떻게 작성했는지에 따라 쿼리의 성능이 차이가 생기겠죠.

데이터가 많아질수록 그 영향은 더 커질 겁니다.

 

그렇다면 쿼리를 작성할 때 기본적으로 고려하면 좋은 점들을 쿼리 초보자 입장에서 정리해보았습니다.

 

 

  1. Select * 보다는 필요한 컬럼만 불러온다
    => 서비스에서 나중에 쓰일 것 같은 컬럼을 일단 가져오고 서비스에서는 쓰지 않는 경우가 종종 있습니다.
    => 하지만, 모든 컬럼을 조회하면 그만큼 DB에 부담을 주기 때문에 필요한 컬럼만 가져오는 게 성능에 좋습니다.
  2. Index를 타고 있는지 확인하자
    => 정의된 index가 있는지, 있다면 index를 탈수 있도록 where절의 조건과 순서를 조정해서, index를 활용하는 편이 당연히 성능이 좋겠죠.
  3. 쿼리의 실행 순서를 기억하자.
    => From, On, Join, Where, Group, Having, Select, Order by 순서대로 실행됩니다.
    => 따라서 From, On, Join, Where, Having 순으로 Query가 확장될 때, 해당하는 대상을 줄여줄 수 있도록 작성해야 합니다.
    => 같은 조건이라도, having에 적용할 때보다, where절에서 필요한 만큼만 가져오는 게 성능이 더 좋다고 합니다.
    그리고, 쿼리의 실행 순서가 ALIAS 순서이니까 알아두는 게 좋겠죠,
    (From 절에서 alias 하면 where절에서 사용 가능, Select에서 alias하면 where 절에서 사용 불가능)
  4. Join 되는 결과 테이블의 크기를 줄여야 한다.
    => JOIN시 on절에 의해 추려지는 데이터는 메모리에서 관리하게 되므로, on으로 추릴 때 이왕이면 데이터의 중복이나, 양을 최대한 줄일 수 있도록 설정해야 성능에 도움이 된다고 합니다.
    =>그래서 Left outer join 보다는 inner join을 사용하자
    같은 데이터를 뽑아낼 거면 Left outer join으로 null로 join 되는 걸 가져온 후 다시 제외하는 것보다,
    한 번에 inner join을 사용하는 게 성능상 좋겠죠.
  5. Where절에서 데이터 타입을 일치해야 한다.
    => Where id = '1'과 Where id = 1 이 있는데, id의 데이터 타입이 문자형이라면 인덱스를 활용할 수 있으므로 더 성능이 좋다고 합니다.
  6. Distinct는 자제하자
    =>  Distinct는 정렬에 따른 성능에 하락이 발생하기 때문에 필요한 경우에만 사용하는 게 좋다고 합니다.
  7. Union 보다 Union all을 사용하자
    => Union 은 중복 검사를 하기 때문에 성능 차이가 꽤 크게 납니다... 참고!

 

다시 한번 정리하면서 느낀거지만..

DB도 결국 프로세스 대로 실행이 되기 때문에.

필요한 만큼만, 최대한 사이즈를 줄여서 가져오는게 성능상 좋은것 같네요.

 

이상입니다 :)

반응형

+ Recent posts