it개발자스터디공간

고려사항5. Subquery

*Subquery의 정의

-메인쿼리에 종속되는 하위의 쿼리를 의미함

-종속의 의미는 반드시 메인쿼리의 집합 레벨을 변경할 수 없음

-메인쿼리는 서브쿼리의 모든 속성을 사용할 수 없음

-서브쿼리는 메인쿼리의 모든 속성을 사용할 수 없음

-대표적인 연산자로는 IN, EXISTS가 있음

*제공자형 서브쿼리

-메인쿼리의 처리범위를 줄여줄 수 있을 때 사용 고려

-메인쿼리에 상수값을 공급한는 것과 동일한 효과를 얻을 수 있음

-서브쿼리로부터 상수값을 공급받는 Where절의 조건에 인덱스가 필요함

*확인자형 서브쿼리

-메인쿼리에서 산출된 결과가 다른 테이블의 조건을 만족하는지 여부를 확인하고자 할때 사용

-만족하는 결과만 존재하면 처리를 더 이상 만족하는 로우를 찾지 않음으로 처리가 빠름

고려사항4. inline View

*Inline View의 정의

-인라인 뷰란 FROM 절 상에 오는 서브쿼리로서 VIEW처럼 동작을 함

-적절한 크기의 중간집합을 생성하기 위하여 사용됨

-데이터 처리의 순서를 의도적으로 지정하기 위해 사용됨

-정상적이지 않은 데이터 구조를 연결하기 위해 사용됨

-실행계획의 제어를 위한 목적으로 사용됨

*Inline View vs View vs Subquery Factoring

고려사항3. JOIN LINK

*연결고리(Join Link)란 무엇인가?

-Where절에서 조인에 참여하는 각 테이블의 컬럼 간 다양한 연산자(=,<>,=, in...)로 연결되어 있는 부분을 연결고리라고 함

*연결고리 종류

-연결고리는 오로지'='만 존재하는 것이 아님

​

*연결고리 상태

-양쪽 정상

 。조인 오더에 상관없이 항상 인덱스를 사용

 。양쪽 연결고리가 정상일 경우 처리범위가 적은 테이블부터 드라이빙 되는 것이 유리

-한쪽 정상

 。논리적으로 연결고리가 비정상인 테이블(연결고리에 인덱스가 사용할 수 없는 테이블)에서 연결고리가 정상적인 테이블로의 조인오더는 양쪽 정상과 같이 문제가 되지 않음

 。단, 반대의 경우로 수행이 될 경우 성능상의 문제를 야기할 수 있음

-양쪽 이상

 。대부분 Nested Loops 조인 형태 보다는 Hash Join으로 풀리게 된느 경우가 대부분임

고려사항2. JOIN Order

*Driving Table

-드라이빙 테이블이란 두개의 테이블이 조인을 할 경우 먼저 처리 되는 테이블을 의미한다.

-WHERE절의 상수 조건에 가용할 수 있는 인덱스가 존재해야 함

*Driven Table

-두 개의 테이블이 조인을 할 경우 뒤에 처리되는 테이블을 의미한다.

-드라이빙 테이블로부터 상수값을 공급받아 처리됨

-연결고리를 통해 상수 값은 공급받게 됨

-따라서, 연결고리에 인덱스가 정상적으로 존재해야 함

-또는, 연결고리와 WHERE절의 상수조건을 포함한 인덱스가 존재해야 함

*최적화된 Join Order란?

-모든 연결고리가 정상상태일 경우 처리범위가 적은 쪽에서 부터 드라이빙 되도록 처리하는 것이 일반적으로 최적화된 조인 오더임

​

고려사항 1. JOIN Method

。SQL은 쉽다?

*'WHAT'만 필요할 뿐 'HOW'는 필요없다.

*배우기가 쉽다.

 -SELECT, FROM, WHERE

 -프로그램을 모르는 END-USER도 손쉽게 SQL을 작성할 수 있다.

*동일한 결과를 얻을 수 있는 방법은 수도 없이 많다.

。SQL 어렵다?

*최적의 SQL을 작성하는 것은 쉽지 않다.

*SQL은 SELECT, FROM, WHERE절만 알아서 되는 것은 아니다.

*수행되는 과정을 정의할 수 없다.->성능을 담보할 수 없다.

*생각하지 않은 SQL을 성능을 보장 받을 수 없다!

。그렇다면 어떻게 해야 최적의 SQL을 작성할 수 있을까?

​