•
서브쿼리는 일시적인 테이블이다 
영속화한 것이 뷰다.
영속화한 것이 뷰다.
21강 - 서브쿼리가 일으키는 폐해
•
연산 비용 추가
서브쿼리를 이용해 SELECT를 할 때마다 실행-데이터 생성이 이뤄진다.
•
데이터 I/O 비용 발생
연산 결과를 미리 저장해놓아야하기 때문에 메모리를 사용하고, 더 나아가서 TEMP 탈락이 일어날 수 있다.
•
최적화를 받을 수 없음
테이블과는 다르게 메타데이터가 없으므로 옵티마이저나 성능적인 최적화의 도움을 받을 수 없다.
장단점
서브쿼리의 유연성과 작성시의 용이함이 있지만, 성능적으로 문제가 될 여지가 많다.
한편 서브쿼리를 쓰는 때에 따라서 성능 개선에도 도움이 될 수도, 아닐 수도 있다.
근본적으로 실행 계획을 토대로 보았을 때에, 서브쿼리로 인한 추가적인 스캔 수를 줄이는 것이 중요하다.
SQL 튜닝에서 가장 중요한 부분은 I/O를 줄이는 것이다
윈도우 함수를 이용하는 방법을 통해 스캔의 횟수를 줄이는 것을 생각해볼 수 있다.
결합 알고리즘은 실행계획의 변동을 고려해야 한다
즉, 장기적인 관점에서의 리스크를 감수하고 관리해야 한다는 점을 알아야 한다. ← 하지만 MySQL의 경우에는 알고리즘이 하나이니까.. 성능 개선에 집중하면 될 것 같다.
결합을 지양하고 윈도우 함수와 CASE를 이용하여 작성하는 것을 고려하라
22강 - 서브쿼리 사용이 더 나은 경우
•
결합과 관련된 쿼리일 때, 서브쿼리를 사용하는 편이 성능 측면에서 더 나은 경우가 있다.
→ 결합하는 대상 레코드 수를 줄이는 것이 중요하다.
→ 옵티마이저가 이부분을 잘 판별하지 못할 때, 직접 연산의 순서를 명시(적은 방향으로)하면 좋은 결과를 얻을 수 있다.
•
결국 서브쿼리를 통해 결합되는 레코드의 수를 줄일 수 있다면 좋게 바꿀 수 있는 여지가 있는 것이다. && TEMP 탈락이 없다면 해당하는 만큼의 비용은 적절한 트레이드오프다.