10. 그래픽 실행 계획의 기초 - WHERE절의 추가

WHERE절의 추가

 

설명에 앞서 아래의 쿼리를 실행해보자. 앞서 9. 그래픽 실행 계획 기초 - Table Joins 에서 사용된 쿼리에서 WHERE절이 추가 되었다.

 

SELECT e.[Title], a.[City], c.[LastName] + ',' + c.[FirstName] AS EmployeeName FROM [HumanResources].[Employee] e JOIN [HumanResources].[EmployeeAddress] ed ON e.[EmployeeID] = ed.[EmployeeID] JOIN [Person].[Address] a ON [ed].[AddressID] = [a].[AddressID] JOIN [Person].[Contact] c ON e.[ContactID] = c.[ContactID] WHERE e.[Title] = 'Production Technician - WC20' ;

 

실행 계획은 다음과 같다.

 

[그림 1] WHERE절을 추가했을 때의 실질 실행 계획 

 

먼저, 쿼리 옵티마이저는 Primary Key인 PK_Employee_EmployeeID를 Clustered Index Scan하기 위해 WHERE절을 통해 판단하고 있다. Clustered Index Scan 연산자의 ToolTip을 보면 WHERE절에 의해 예상 행 수가 22행으로 제한되고 있다.

 

[그림 2] Clustered Index Scan의 ToolTip

 

9. 그래픽 실행 계획 기초 - Table Joins에서의 실행 계획과 비교해 보도록 하자.

 

우선, WHERE조건에 의해 22행으로 선행 집합이 상당히 좁혀졌고, [Person].[Contact]에서도 좋은 인덱스를 선택하였기 때문에, 이번에는 쿼리 옵티마이저가 Hash Match Join보다 유용한 Nested Loops Join을 이용할 수 있다. 조인 방식이 바뀜에 따라 Scalar 연산 또한 이 조인의 바로 다음으로 이동되었다. Scalar 연산을 통해 얻어진 결과 - 22행만 Scalar 연산을 하면 된다 - 는 다시, [HumanResources].[EmployeeAddress] 테이블과 [Person].[Address] 테이블을 차례로 Nested Loops Join을 하여 최종 결과를 얻어낸다. 이 때 각각의 테이블에서는 Clustered Index Seek 연산을 하였다.

 

어떤가? 9. 그래픽 실행 계획 기초 - Table Joins에서의 실행 계획보다 상당히 효율적이지 않은가? 이는 모두 WHERE 절에서 초기 집합을 줄였기 때문에 가능한 것이다.

 

 

다음 이야기 : 11. 그래픽 실행 계획의 기초 - GROUP BY와 ORDER BY가 있는 쿼리에서의 실행 계획