답변.

문제의 역사:

중첩 서브쿼리는 SQL에서 언어의 표현 능력을 확장하고 간단한 SELECT 연산으로 해결할 수 없는 복잡한 비즈니스 문제를 해결하기 위해 처음 설계되었습니다. 그러나 데이터 양과 관계 모델의 복잡성이 증가함에 따라, 항상 중첩 서브쿼리가 효율적으로 작동하는 것은 아니라는 인식이 생겼습니다. 이는 특정 데이터베이스 최적화 프로그램의 구현에 따라 다릅니다.

문제:

주요 도전 과제는 가독성, 논리의 정확성 및 성능 간의 절충점을 찾는 것입니다. 중첩 서브쿼리가 항상 조인 연산으로 최적화되는 것은 아니며, 종종 비용이 많이 드는 반복 루프(Nested Loops)로 변환됩니다.

해결책:

다른 방법이 불가능할 경우 집계나 복잡한 표현식을 계산하기 위해 SELECT에서 중첩 서브쿼리를 사용하십시오.
대용량 데이터의 경우 조인으로 전환하는 것이 좋습니다. 이렇게 하면 최적화 프로그램이 쿼리를 집합 기반으로 만들고 인덱스를 적용할 수 있습니다.
가독성이나 성능을 높이기 위해 서브쿼리를 외부로 끌어내기(대체 WITH/CTE)를 고려하십시오.

코드 예시:

-- SELECT에서의 중첩 서브쿼리 (신중하게 사용!)
SELECT name, (SELECT COUNT(*) FROM orders WHERE orders.client_id = clients.id) AS order_count
FROM clients;

-- 조인으로의 동등한 쿼리 (보통 더 빠름):
SELECT clients.name, COUNT(orders.id) AS order_count
FROM clients
LEFT JOIN orders ON orders.client_id = clients.id
GROUP BY clients.name;

주요 특징:

중첩 상관 서브쿼리는 종종 O(N*M)의 성능 저하를 초래합니다.
비상관 서브쿼리는 더 안전하고 빠릅니다.
WITH/CTE 또는 조인으로 서브쿼리를 외부로 끌어내면 계획의 예측 가능성이 높아지고 실행 속도가 빨라집니다.

함정 질문.

SELECT에서의 중첩 서브쿼리는 유사한 LEFT JOIN보다 빠른가요?

대개 — 아니요. SELECT에서의 상관 서브쿼리는 외부 쿼리의 각 행마다 실행되는 반면, 조인은 전체 테이블에 대해 인덱스와 함께 한 번만 이루어집니다.

CTE(WITH) 대신 FROM에서 서브쿼리를 사용할 수 있으며, 차이가 있을까요?

네, FROM에서 서브쿼리를 사용할 수 있습니다:

SELECT t1.id, sub.agg
FROM table1 t1
JOIN (SELECT id, MAX(val) AS agg FROM table2 GROUP BY id) sub ON t1.id = sub.id;

하지만 CTE는 때때로 가독성이 높고 실행 계획에서 다른 최적화를 초래할 수 있습니다.

모든 중첩 서브쿼리는 유사한 JOIN으로 최적화되나요?

아니요. 모든 데이터베이스가 이를 동일하게 수행할 수 있는 것은 아니며, 때때로 중첩 서브쿼리는 각 행을 스캔하게 됩니다. 특히 외부 쿼리와 내부 쿼리 간에 상관 관계가 있는 경우 더욱 그렇습니다.

전형적인 실수 및 안티 패턴

대용량 시 SELECT에서 상관 중첩 서브쿼리 사용.
내부 및 외부 쿼리에서 필터 조건 중복.
모든 중첩 서브쿼리를 JOIN으로 대체하려는 시도.

실제 사례

부정적인 사례

판매 관리자가 클라이언트에 대한 보고서를 작성할 때 내부 SELECT로 주문 수를 계산했습니다. 실행 시간은 몇 분이 걸리며 서버에 대한 부하는 기하급수적으로 증가했습니다.

장점:

명확한 논리 단점:
많은 클라이언트에 대한 매우 느린 보고서
비효율적인 서버 부하

긍정적인 사례

LEFT JOIN과 그룹화를 사용하여 쿼리를 재작성했습니다.