SQL튜닝을 내가 잘 하는건 아니고, 요즘은 배워나가는 단계임
울회사랑 협력사가 금융권에 많아서(우리도 금융권에 주로 납품..) OLAP성 쿼리 튜닝할 일이 좀 있는데,
어쨌든 대충 튜닝은 이런식임
Plan을 본다
실데이터가 있으면 좋다.(애초에 실데이터 안주면 튜닝 안함 시발) 없어도 가능하지만 좆같이 불편하다.
소모시간을 확인해보면 대충 어떻게 탔길래 느려졌는지 나온다.
원인은 다양함. 가장 흔한 이슈 중 하나는 쿼리 조건에 따라 Full scan이 뜬다던가,
인덱스를 엄한 걸 탄다던가, join조건을 너무 광범위하게 잡아서 큰 데이터->작은 데이터 순으로 올라가는 상황이 발생한다던가.
사실 쿼리튜닝은 단 한가지 목적으로 진행됨. low level에서 최대한 도출되는 수를 줄여서 조건을 빡세게 만들어주고, 그 뒤의 쿼리는 빠르게 진행될 수 있도록 하는거지.
즉 케이스를 줄이는 행위가 튜닝임.
쿼리 A 에서 where걸고 서브쿼리 B에서 풀스캔을 하는것보다,
쿼리 A의 where조건을 최대한 서브쿼리 B에다가 붙여주면 서브쿼리 B는 풀스캔을 하지 않고 인덱스를 타면서 시간이 줄겠지.
보통 그런식이지만 예외상황은 허벌나게 많아서 항상 그게 해결책이 될 순 없음.
예외가 너무많을텐데 어케 통합함?
예외라는건 내가 든 예시를 말하는 거고 간단한 튜닝은 보통 저런식으로만 해도 해결되는 경우가 많음. 조인조건 따라서 이상한 인덱스 탄다던가 조인 구조를 풀어서 조건을 안으로 이동한다던가... 정해진 튜닝법이란 거 자체가 없음
db쪽 어캐가나요
DBMS회사(개발, 엔지니어, 영업도 가능은 할듯), DB 미들웨어 회사(DB툴이라던가 암호화라던가..), 쌩DBA 정도? 개발하다가 갈아타는 분들도 많습니다.
오 요새 디비공부하는데 막 읽혀요 신기 - dc App