정확한 데이터가 나오게 함과 동시에 쿼리가 돌아가는 구조를 이해 하면서 만들면 튜닝은 어떻게든 됩니다.
쿼리 돌아가는 구조를 이해해야 한다고 하는 이유는 현업에서 이런 케이스를 너무 많이 봐서 입니다.
create function f1(ipt1 varchar2(100)) returnc varchar2
is
output varchar2(100);
begin
select c1 into output from table2 b where b.c2=ipt1;
return output;
end;
select f1(a.col1) from table1 a where col2='COL2'; -- 결과는 10만건 정도
적당히 만든거라 문법 오류 날거 같지만...이런 유형 많이 봤는데 이렇게 쿼리 짜고 튜닝 요청하면 DBA 열받습니다. 이런 쿼리는 결과 제대로 나와도 다 뜯어야 합니다.
제가 이곳 사이트에서 SQL질문에 대한 답을 달면서 느꼈던 점입니다.
복잡하게 작성한 쿼리에 대한 튜닝 요청 쿼리 중 대다수가 틀린 쿼리였습니다.
테이블 간의 관계를 이해하고 최대한 간결하게 작성해야 합니다.
결과 맞추기에 급급하다 보면 쿼리가 복잡해 지며
쿼리가 복잡해 질 수록 틀린 쿼리가 될 가능성이 높아집니다.
나쁜 쿼리와 틀린 쿼리는 전혀 다르죠.
(나쁜쿼리 = 느린쿼리) <> (틀린쿼리=부정확한결과=요구사항을 충족하지 않는 쿼리)
추가로 가독성이 좋은 쿼리입니다.
조금 복잡한 쿼리라도
가지런하게 들여쓰기와 내려쓰기를 적절하게 사용하고,
대문자와 소문자를 구별하여 작성한 쿼리가 좋은 쿼리입니다.
- 들여쓰기 : 서브쿼리 깊이에 따라 들여쓰기
- 내려쓰기 : SELECT, FROM, WHERE 등을 한줄에 다쓰지 않기
SELECT, FROM, WHERE 에 들어가는 LIST 도 한줄에 다쓰지 않기
- 대문자 : 예약어(기본 명령어)
- 소문자 : 사용자 정의어(테이블, 컬럼, 함수 등)