DB마다 구현이 많이 많이 달라서 튜닝 방법도 많이 많이 다르다


1. 튜닝은 인덱스/쿼리 튜닝이다.



2. Cost-Based Optimizer(CBO)

쿼리 튜닝은 CBO가 알아서 해준다.

RDB에서 가장 중요한 기능임.

우리가 할 일은 CBO가 뻘짓할 때, 가이드하는 것 뿐

쿼리 좆같이 짜면 CBO가 뻘짓하니까 이상한 짓 하려고 하지마셈 ㅇㅅㅇㅋㅋㅋ



3. 쿼리는 OLTP / OLAP 2종으로 나눈다

OLTP는 단문 쿼리. Index Seek. 주로 서비스 로직. 길어야 몇 페이지

OLAP는 장문 쿼리. Scan. 주로 통계 로직. 길면 만줄 가볍게 넘음


RDB 엔진은 이걸 철저히 구분해서 다른 알고리즘을 쓰므로

이걸 구분해서 올바른 알고리즘을 쓰는지 봐야 한다


OLAP 쿼리 튜닝은 땔감이 할 수 있는게 아니니 DBA에 패스하셈

사실 대부분 OLAP 쿼리 만질 일도 없을거고 앵간한 DBA도 튜닝 제대로 못 할거임 ㅇㅅㅇㅋㅋㅋ



4. 조건절에서 불필요한 짓 절대 하지 마라

조건절에 변수만 써도 인덱스를 못 쓰는 경우가 생긴다.

SARG(search arguments) 공부해보셈

RDB는 민감한 놈이라 조금만 수틀리면 성능이 훅훅 떨어짐

진짜 어처구니 없는 조건으로 SARG가 안 되서 성능 떨어짐 ㅇㅅㅇㅋㅋㅋ



5. 인덱스

인덱스의 중요성은 아무리 강조해도 지나치지 않긴 한데 귀찮아서 짧게 하겠음

랜덤 엑세스 하는 곳에는 nonclustered index 

스캔 하는 곳에는 clustered index를 거는게 좋고

인덱스도 일종의 테이블이며

검색하는 컬럼이 다 인덱스에 포함된 경우, covering index라고 부르는데 이 경우 존나게 빨라짐 



6. 나머지는 내용이 길어지기도 하고 특정 DBMS 벤더 특화 내용이라 생략함



7. 마지막으로... 쿼리 튜닝이란 뭔가?

연산에 참여하는 행열의 크기를 최소화. 물리적으로 적게 읽는게 빠른 것

너무 당연한 이야기지만 비지니스 로직에서 이게 잘 되는 경우는 드물다

그러니까 쿼리 튜닝 전문으로 먹고 사는 사람들이 있겠지 ㅇㅅㅇㅋㅋㅋ


당연하지만 인덱스만 잘 걸면 반은 먹고 들어간다

좆간은 옵티마이저가 잘못 돌지 않게 거들 뿐이어서 프로그램 최적화랑 방향이 좀 많이 다름


프로시저에 코딩하려고 하지마라

프로시저는 실행할 때, 컴파일해서 재활용하는데

로직 복잡하면 실행할 때마다 컴파일해서 더 느려지기도 하고 그럼


이런 복잡한 것들이 DBMS 벤더마다 다 다르고

내부가 어떻게 구현되었는지는 비공개이기 때문에 경험과 추측에 의존해야하는 사이비 분야이다 ㅇㅅㅇㅋㅋㅋ