얼마 전 Brent Ozar는 SQL Server와 PostgreSQL의 차이점을 자세하게 설명하는 게시물을 게시했습니다.
SQL Server와 PostgreSQL의 두 가지 중요한 차이점
첫 번째 요점 ( "CTE는 최적화 펜스")은 제공된 예에서 SQL Server가 CTE와 기본 쿼리를 함께 결합하여 단일 쿼리로 최적화한다는 점이 분명하기 때문에 내 시선을 사로 잡았습니다. PostgreSQL).
그러나이 동작은 SQL Server가 CTE를 최적화 펜스로 취급하는 다른 블로그 및 교육 클래스에서 본 예제와는 반대되는 것처럼 보입니다. 인덱스를 더 잘 사용하고 성능을 향상시킬 수 있습니다. 예를 들면 다음과 같습니다.
따라서 SQL Server는 최적화 울타리 SOMETIMES로 CTE를 "명예롭게"하는 것처럼 보입니다. SQL Server가 CTE를 최적화 차단 (또는 반대 동작)으로 신뢰할 수있는 알려진 사례의 특정 목록을 문서화 할 수있는 유용한 리소스가 있습니까?
답변:
... SQL Server가 CTE를 최적화 펜스로 신뢰할 수있는 알려진 사례 목록
이러한 목록은 신뢰성을 보장하지 않고 관찰 된 동작에 의존합니다.
SQL Server 쿼리 옵티마이 저는 공통 테이블 표현식을 최적화 펜스 자체 로 취급하지 않지만, 일부 구성은 전체적으로 최적화하기가 어렵습니다. 재귀 적 CTE가 이에 대한 좋은 예입니다.
CTE는 뷰 / 인라인 함수 / 서브 쿼리 / 유도 테이블과 매우 유사하게 처리되며 쿼리에 인라인됩니다. 관찰 된 '울타리'행동은 원칙적으로 투수 가능한 경계를 넘어 최적화 할 수 없거나 최적화하지 않기로 결정한 옵티 마이저에 달려 있습니다.
일반적으로 CTE가 더 단순하고 '관계가있는'경우, 옵티마이 저가 비트를 이동할 수있을 가능성이 높습니다.
옵티마이 저가 CTE의 '결과'를 고려하거나 강제로 구현할 수있는 기능이 제안되었지만 아직 구현되지 않았습니다.
그 동안 가장 일반적인 해결 방법은 임시 테이블 또는 테이블 변수에 중간 결과 집합을 명시 적으로 구체화하는 것입니다. 이것은 분명히 단일 진술로 제한되지 않는 시나리오를 요구합니다.