쿼리 최적화 - oracle 서브쿼리 튜닝

Question

SELECT * FROM some_table WHERE some_column IN ( SELECT array_column FROM another_table WHERE some_condition ); 이 쿼리를 날렸을 때 실행계획이 some_table 접근 시 in 절을 hash join 에 option은 right semi 로 실행계획을 풀어버립니다.저는 단순히 in 절을 실행계획으로 or 로 풀어버리고 싶었을 뿐이고 some_column 에도 인덱스가 걸려있습니다.서브쿼리에 no_unnest 로 힌트를 줘서 filter 조건으로 풀어버려도 exists 로 실행계획이 바뀌긴하는데 full scan 으로 타버려 시간이 또 지연됩니다.. 어떻게 풀어야할까요..

Clickin · Answer

조인으로 가능한 방식인 듯 한데 굳이 서브쿼리로 해야하는 사유가 있나요?그와는 별개로 서브쿼리에도 힌트를 줄 수 있으니 서브쿼리에 인덱스 힌트를 한번 줘보시는건 어떨까요

장독깨기 · Answer

조인으로 하고 힌트로 조절해보면 어떨까 합니다.

르매 · Answer

join으로 푸는 것이 맞고 쿼리를 IN으로 구성해도 결국 옵티마이저는 join으로 실행계획을 세우죠.과거에는 옵티마이저가 join으로 변환하지 않았던 시절이 있었는데, 그때 IN을 사용하면 쿼리 실행이 굉장히 느려지는 상황이 많았습니다. 그래서 지금의 옵티마이저는 IN을 알아서 JOIN으로 풀어 줍니다. 사실 IN은 빠를 것 같아 보이지만 실제로는 or 연산이기 때문에 서브쿼리가 반환하는 행의 수가 많아지면 성능이 굉장히 나빠집니다.각설하고.. 본문의 쿼리가 느린 이유는 some_column에 있다는 인덱스를 seek하지 못하기 때문입니다. 이 인덱스가 사용될 수 있는 쿼리였다면 hash가 나오지 않습니다. 더구나 서브쿼리의 결과가 서너개라면 NL 조인이 나올테니 빠르게 결과가 나왔을겁니다.어쨌든쿼리를 IN으로 작성하건 JOIN으로 작성하건.. 옵티마이저는 JOIN으로 풉니다.위 쿼리가 느린 이유는 아마.. some_column과 array_column의 데이터 유형이 서로 일치하지 않는게 아닐까 의심해 봅니다. 만약 그렇다면 array_column을 cast 연산자로 형 변환하여 some_column과 맞춰주면 해결 될 듯 하네요.어떤 경우에도 IN이 JOIN보다 빠른 경우는 없습니다. 지금 빠르다고 생각하시는 이유는.. IN 절 안에 상수를 넣어서 실행하고 비교하셨기 때문인데요. 이 상수가 some_column의 인덱스를 seek하는데 적합했기 때문에 빠른 것이지 IN이라서 빠른 게 아닙니다. 상수와 비교할 때는 인덱스를 타는데 array_column과 비교할 때는 인덱스를 안탄다? 그럼 array_column 컬럼의 타입을 의심해야 합니다.

쿼리 최적화 - > oracle 서브쿼리 튜닝

3개의 답변

Q&A 목록