SQL Server Join / where 처리 순서

느린 SQL 쿼리를 읽은 후 최적화 방법을 모르면 쿼리의 일반적인 성능에 대해 생각하게되었습니다. 확실히 쿼리를 조금 더 빨리 만들려면 첫 번째 테이블의 결과 (다른 테이블이 조인 된 경우)가 조인하기 전에 (이 질문의 내부 조인) 가능한 한 작아야합니다.

예를 들면 다음과 같습니다.

SELECT *
FROM   ( SELECT * FROM table1 WHERE col = @val ) t
INNER JOIN table2 ON col = col2

다음보다 낫거나 빠릅니다.

SELECT *
FROM table1
INNER JOIN table2 ON col = col2
WHERE table1.col = @val

내 이론은 다음과 같습니다 (올바른 구현이 아닐 수도 있습니다 (MSFT Press)는 SQL Server 2008 내부 서적을 기억하려고합니다).

1. 쿼리 프로세서는 먼저 왼쪽 테이블 (table1)을 가져옵니다.
2. 필요한 행을 필터링하기 전에 두 번째 테이블 (table2)을 결합하고 직교 곱을 형성합니다 (해당되는 경우).
3. 그런 다음 SEELCT 문을 마지막으로 사용하여 WHERE, ORDER BY, GROUP BY, HAVING 절을 수행하십시오.

따라서 위의 명령문 # 1에서 테이블이 더 작 으면 SQL 엔진은 직교 곱을 작성할 때 수행 할 작업이 줄어 듭니다. 그런 다음 where 문에 도달하면 메모리에서 필터링 할 결과 집합이 줄어 듭니다.

나는 그것이 비현실적이라고 마크에서 너무 멀 수 있습니다. 내가 말했듯이, 그것은 이론입니다.

당신의 생각?

참고 : 나는 단지이 질문에 대해서만 생각했으며 아직 내 테스트를 실행할 기회가 없었습니다.

참고 2 : MySql 등의 구현에 대해 아무것도 모르기 때문에 SQL Server로 태그 지정되었습니다 .

쿼리의 논리적 처리는 MSDN에서 수행됩니다 (타사가 아닌 Microsoft SQL Server 팀에서 작성).

1. FROM
2. ON
3. JOIN
4. WHERE
5. GROUP BY
6. WITH CUBE or WITH ROLLUP
7. HAVING
8. SELECT
9. DISTINCT
10. ORDER BY
11. TOP

파생 테이블은 다음과 같습니다. 외부 쿼리는 다시 수행합니다.

이것은 논리적 이지만 실제가 아닙니다 . SQL Server가 실제로 수행하는 방식에 관계없이 이러한 의미는 문자 로 인정 됩니다 . "실제"는 Query Optimiser (QO)에 의해 결정되며 언급 한 중간 Cartesion 제품을 피합니다.

SQL이 선언적이라고 언급 할 가치가 있습니다. 절차 / 제국 프로그래밍 (Java, .net)에서와 같이 "어떻게" "어떻게"말하겠습니까? 따라서 많은 경우 "이 전에 발생합니다"라고 말하는 것은 잘못입니다 (예 : 단락 또는 L-to-R WHERE 순서 가정)

위의 경우 QO는 간단한 쿼리이기 때문에 구조가 어떻게 구성 되든지 동일한 계획을 생성합니다.

그러나 QO는 비용 기반이며 복잡한 쿼리의 경우 이상적인 계획을 생성하는 데 2 ​​주가 걸릴 수 있습니다. 실제로는 "충분히"충분하지 않습니다.

따라서 첫 번째 경우는 논리적 처리 순서가 두 쿼리에 대해 다르므로 옵티마이 저가 더 나은 계획을 찾는 데 도움이 될 수 있습니다. 그러나 그렇지 않을 수도 있습니다.

SQL Server 2000에서이 트릭을 사용하여보고 쿼리의 성능을 60 배 빠르게 향상 시켰습니다. QO가 버전을 개선함에 따라 이러한 작업을 더 잘 수행 할 수 있습니다.

그리고 당신이 언급 한 책 : 그것에 대해 약간의 분쟁이 있습니다
.SO와 후속 링크를 참조하십시오 : https : //.com/q/3270338/27535

SQL 쿼리는 본질적으로 절차 적이 지 않으며 결합 연산자에 대한 하향식 처리는 없습니다. 예제 쿼리에서 테이블의 순서 는 논리적으로 동일하고 정확히 동일한 계획을 생성 하므로 실행 계획 에 영향을 미치지 않습니다 .

쿼리 최적화 프로그램 이이 쿼리에 대한 계획을 생성 할 때 고려할 수 있는 두 가지 옵션을 평가했습니다 . 계획 선택에 영향을 미치는 주요 요인은 관련 테이블에 대한 통계 와 후보 계획에서 운영자 선택과 관련된 비용 입니다.

예제와 같은 매우 간단한 두 테이블 조인은 수백 가지의 다른 실행 계획 중 하나를 만족시킬 수 있습니다. 옵티마이 저는 이러한 계획의 비용을 비교하여 쿼리에 가장 적합한 방법을 결정합니다.

때로는 잘못되기 때문에 향상된 색인 생성, 통계 업데이트 및 힌트 적용을 통해 더 나은 선택을 할 수 있습니다. 매우 드문 경우이지만 FORCE ORDER 힌트를 사용하여 강제로 실행 순서를 적용하고 싶을 수 있지만 드물게 사용해야합니다. 너트를 깨뜨리는 것은 망치이며, 옵티마이 저는 일반적으로 더 나은 정보를 제공함으로써 더 나은 계획을 세우는 데 관심을 가질 수 있습니다.