안녕하세요..
튜닝할때 궁금한게 있는데요..
풀쿼리로 돌아가는 테이블 보면서 PK키나 인덱스잡아주면서 CPU Cost를 줄이고 있거든요.
근데 거의다 키를 잡아서 줄였는데도 속도가 향상되는 느낌은 들지가 않아서요..
그래서 했던게 잘못된건지 궁금해서 여기에 여쭤봅니다..
1. 튜닝속도는 CPU Cost와 관련이 없는건가요??
- 지금까지 CPU Cost를 기준으로 속도차이가 나는걸로 이해했는데 그게 아닌거면 정확히 어떤 결과가 나오면 속도가 향상되는지 알려주시면 감사하겠습니다..ㅜㅜ
2. Full Acess 테이블을 변경하다보니 대부분이 Select 안에 Sub쿼리로 변경을 했는데 이렇게하면 속도차이가 안나는건가요??
- 개념상으로는 Select문안에 Sub쿼리가 많으면 속도가 느려진다는건 맞는거 같는데 CPU Cost는 줄어들었거든요..
Full로 돌리면 300mb 잡았던 CPU Cost가 4mb때로 확줄었거든요.. 대신 각각 한개씩 돌려서 한번돌리는걸 2번,3번 돌리게 되고 있구요..
(기존 -> 테이블 풀쿼리로 MAX, MIN, COUNT등을 구한 테이블뷰와 다른테이블간 조건으로 돌림)
(수정 -> 어떤건 해당컬럼의 Max값 서브쿼리, 어떤건 해당컬럼의 Min값 서브쿼리, 어떤건 해당컬럼의 Count값 서브쿼리)
3. 아님 단순히 조회하려는 날짜범위가 너무 커서 그런건가요??
- 날짜를 지금 4년치로 조회시키고 있는데(원래 조회 기준치는 1년단위), 메모리버퍼를 잡고있어서 그런건지 원쿼리가 튜닝한다고 수정한 쿼리보다 10초정도 빨라요..
최종으로 정리한걸 말씀드리면 실행계획이 총 79작업에서 74작업으로 얼마 줄지는 않았구요.
CPU cost는 총 710M 잡고있던 걸 45M까지 내렸는데 지금 계속 작업중이긴해서 더줄일생각이에요.
근데 CPU Cost만 줄인다고 해결될거 같지 않아서요..ㅜ
잘못된 방향으로 가고있다면 지적좀 부탁드립니다..
index전략을 조건절로 정확하게 잡았다고해도
select 절에 표현되는 컬럼이 값으로 인하여
table access
ㄴ index
형태의 플랜을 보시게됩니다.
그렇다면 index를 조건절로 수행했다면 select 절의 내용으로 인하여서
table을 한번더 반복적으로 찾는 과정으로 문제가 생깁니다.
그래서 full 테이블스캔이 빠르게되는것이고요
이유는 full은 한번만 그냥 테이블전체를 다 읽지만
해당조건에 의해서 index 한번 table한번 읽기 때문에 반복적인 작업이 진행됩니다.
서브쿼리가 많다면 해당서브쿼리의 중첩부분에 대해서 with절을 사용하여 집합을 만든다음에
하단의 조건절로 처리하는 쿼리변경을 진행 해보시기 바랍니다.
또한 서브쿼리가 필터가 되느냐 access가 되느냐를 판단이 필요합니다.