서브쿼리(Subquery)의 종류

서브쿼리는 다른 SQL 쿼리 내에서 사용되는 쿼리를 말합니다. 서브쿼리는 데이터를 필터링하거나, 복잡한 연산을 수행하거나, 다른 테이블과의 관계를 표현하는 데 사용됩니다.

서브쿼리는 크게 세 가지 종류로 분류할 수 있습니다: 스칼라 서브쿼리(Scalar Subquery), 코릴레이티드 서브쿼리(Correlated Subquery), 그리고 비코릴레이티드 서브쿼리(Uncorrelated Subquery).

 

1. 스칼라 서브쿼리 (Scalar Subquery): 이 서브쿼리는 단일 값을 반환합니다. 일반적으로 SELECT, WHERE, 또는 HAVING 절에서 사용됩니다.

예시:

SELECT EmployeeName
FROM Employees
WHERE EmployeeID = (SELECT ManagerID FROM Departments WHERE DepartmentName = 'Sales');

위의 쿼리는 'Sales' 부서의 관리자 ID를 찾은 후, 해당 ID를 가진 직원의 이름을 반환합니다.

 

2. 코릴레이티드 서브쿼리 (Correlated Subquery): 이 서브쿼리는 외부 쿼리에 의존하며, 외부 쿼리의 각 행에 대해 실행됩니다.

예시:

SELECT e.EmployeeName
FROM Employees e
WHERE EXISTS (SELECT 1 FROM Sales s WHERE s.EmployeeID = e.EmployeeID);

위의 쿼리는 적어도 하나의 판매 기록이 있는 모든 직원의 이름을 반환합니다.

 

3. 비코릴레이티드 서브쿼리 (Uncorrelated Subquery): 이 서브쿼리는 외부 쿼리와 독립적이며, 단 한 번만 실행됩니다.

예시:

SELECT EmployeeName
FROM Employees
WHERE EmployeeID IN (SELECT EmployeeID FROM Sales);

위의 쿼리는 판매 기록이 있는 모든 직원의 이름을 반환합니다. 이 서브쿼리는 외부 쿼리와 독립적으로 실행되며, 그 결과가 외부 쿼리에 사용됩니다.

 

4. 인라인 뷰 (Inline View): 인라인 뷰는 FROM 절에서 사용되는 서브쿼리입니다. 인라인 뷰는 일시적인 테이블처럼 작동하며, 쿼리가 실행되는 동안만 존재합니다. 이를 통해 더 복잡한 쿼리를 구성하거나, 재사용이 불가능한 연산을 수행할 수 있습니다.

예시:

SELECT e.EmployeeName
FROM (
    SELECT EmployeeID, EmployeeName 
    FROM Employees 
    WHERE Salary > 50000
) e
WHERE e.EmployeeID IN (SELECT EmployeeID FROM Sales);

위의 쿼리는 먼저 연봉이 50,000 이상인 모든 직원의 ID와 이름을 인라인 뷰를 통해 선택합니다. 그 후, 이 인라인 뷰를 사용하여 판매 기록이 있는 직원들만 필터링합니다. 이 경우, 인라인 뷰는 일시적으로 생성되며, 쿼리 실행 후에는 사라집니다.

Join과 Scalar Subquery의 성능 차이

JOIN과 Scalar Subquery는 데이터베이스에서 사용하는 두 가지 다른 방식이지만, 성능 차이는 데이터베이스 관리 시스템(DBMS), 쿼리의 복잡성, 데이터의 크기, 인덱싱 등 여러 요인에 의해 달라질 수 있습니다.

 

JOIN

JOIN은 두 개 이상의 테이블에서 데이터를 결합하는 방식입니다. JOIN을 사용하면, 쿼리는 한 번만 실행되고, 각 테이블의 데이터는 한 번만 읽혀지므로, 대체로 성능이 좋습니다. 또한, 데이터베이스 관리 시스템의 쿼리 최적화기는 JOIN 연산에 대해 많은 최적화 기법을 알고 있으므로, JOIN을 사용하는 쿼리는 일반적으로 서브쿼리를 사용하는 쿼리보다 성능이 더 좋을 수 있습니다.

 

Scalar Subquery

Scalar Subquery는 단일 값을 반환하는 서브쿼리입니다. 이는 주 쿼리의 한 부분, 일반적으로 SELECT, WHERE 또는 HAVING 절에 사용됩니다. Scalar Subquery는 복잡한 쿼리를 더 이해하기 쉽게 만들어주지만, 성능에 영향을 줄 수 있습니다. 서브쿼리는 각각의 결과 행에 대해 실행되므로, 결과 행의 수가 많을 경우 성능이 저하될 수 있습니다.

따라서 일반적으로 JOIN이 Scalar Subquery보다 성능이 더 좋습니다. 하지만 이는 모든 경우에 해당하지는 않으며, 개별적인 상황에 따라 테스트와 조정이 필요합니다. 쿼리의 성능을 최적화하려면, 실행 계획을 확인하고, 필요에 따라 인덱싱 전략을 조정하거나 쿼리 구조를 변경해야 합니다.

Correlated Subquery의 성능

코릴레이티드 서브쿼리(Correlated Subquery)는 외부 쿼리에 의존하는 내부 쿼리를 가리킵니다. 즉, 코릴레이티드 서브쿼리의 실행은 외부 쿼리의 각 행에 대해 일어나며, 그 결과는 각 외부 행에 따라 달라집니다. 이러한 특성 때문에 코릴레이티드 서브쿼리는 종종 성능 이슈를 일으킬 수 있습니다.

코릴레이티드 서브쿼리는 외부 쿼리의 각 행에 대해 별도로 실행되므로, 외부 쿼리가 반환하는 행의 수가 많을수록 해당 서브쿼리를 실행하는 데 필요한 시간이 증가합니다. 따라서, 결과 집합이 큰 경우 코릴레이티드 서브쿼리는 성능 저하를 유발할 수 있습니다.

 

예를 들어, 다음과 같은 코릴레이티드 서브쿼리가 있다고 가정해 봅시다.

SELECT e.emp_name, e.emp_id 
FROM Employees e
WHERE 5 > (SELECT COUNT(*) FROM Sales s WHERE s.emp_id = e.emp_id);

위 쿼리에서, Sales 테이블의 각 행은 Employees 테이블의 각 행에 대해 검사되고, 이로 인해 쿼리의 실행 시간이 길어질 수 있습니다.

 

따라서 가능한 한 코릴레이티드 서브쿼리를 JOIN이나 다른 방법으로 재작성하는 것이 좋습니다. 그러나 이는 항상 가능한 것은 아니며, 쿼리의 복잡성, DBMS의 최적화 능력 등에 따라 달라질 수 있습니다. 일반적으로 코릴레이티드 서브쿼리의 성능 문제는 쿼리 최적화, 적절한 인덱싱 등을 통해 개선할 수 있습니다.