시험 직전 요약장

SELECT c.customer_id,
       (SELECT SUM(o.order_amount)
        FROM   orders o
        WHERE  o.customer_id = c.customer_id
        GROUP BY o.order_status) AS total_amount
FROM   customer c;

한 고객에게 주문 상태가 두 종류 이상이면 상태별 Group이 여러 행을 만들 수 있어 ORA-01427이 발생합니다. 집계 함수를 사용했다는 사실만으로 한 행이 보장되는 것은 아니며, GROUP BY 후 Group 수를 확인해야 합니다.

입력이 없을 때도 구분합니다.

GROUP BY 없음
→ Aggregate 결과 Row 1건
→ SUM 등은 NULL, COUNT는 0

GROUP BY 있음
→ 생성할 Group이 없음
→ 서브쿼리 결과 0행
→ 스칼라 표현식 값 NULL

두 경우 모두 바깥에서는 NULL처럼 보일 수 있지만 내부 Row Source와 COUNT 의미는 다릅니다.

다음 두 형태는 모두 최대 한 행을 요구하지만 사용 위치가 다릅니다.

-- 스칼라 서브쿼리 표현식
SELECT (SELECT MAX(salary) FROM emp)
FROM   dual;

-- 단일행 비교 연산자와 서브쿼리
SELECT employee_id
FROM   emp
WHERE  salary = (SELECT MAX(salary) FROM emp);

스칼라 서브쿼리는 하나의 expr이 필요한 위치에 값을 공급합니다. =, >, < 같은 단일행 비교에서도 오른쪽 서브쿼리가 여러 행을 반환하면 ORA-01427이 발생합니다.

반면 IN, ANY, ALL, EXISTS는 다중행을 처리하도록 설계된 연산자입니다.

= (subquery)
→ 최대 한 행

IN (subquery)
→ 여러 행 가능

EXISTS (subquery)
→ 행 존재 여부

변환과 재사용이 없다고 단순화하면 상관 스칼라 서브쿼리의 비용은 다음과 같이 생각할 수 있습니다.

전체 비용
≈ 바깥 Row Source 생성 비용
 + 바깥 행 수 × 서브쿼리 1회 처리 비용

예를 들어 바깥에서 100,000행이 나오고 서브쿼리 한 번에 평균 3개의 Buffer를 읽는다면 반복 부분만 약 300,000 Buffer가 될 수 있습니다.

Outer A-Rows = 100,000
Subquery Starts = 100,000
Inner Buffers ≈ 300,000

다만 상관 Key가 반복되고 실행 중 결과가 재사용되거나 서브쿼리가 Unnesting되면 실제 Starts와 작업량은 줄어들 수 있습니다.

재사용은 성능 최적화일 뿐 결과 정확성의 전제가 아닙니다.

Cache가 있다고 가정해 SQL을 설계
→ 위험

실제 Starts·Buffers가 감소했는지 확인
→ 올바른 진단

Key NDV가 작아도 재사용률·충돌·Plan 변환은 실행 환경에 따라 달라질 수 있으므로 고정된 Cache 크기나 Hit율을 일반 규칙처럼 사용하지 않습니다.