비트 맵 필터가있는 쿼리 계획은 읽기 까다로울 수 있습니다. 재 파티션 스트림에 대한 BOL 기사 (강조 광산)에서 :
Repartition Streams 연산자는 여러 스트림을 소비하고 여러 레코드 스트림을 생성합니다. 레코드 내용과 형식은 변경되지 않습니다. 쿼리 최적화 프로그램이 비트 맵 필터를 사용하면 출력 스트림의 행 수가 줄어 듭니다.
또한 비트 맵 필터 관련 기사 도 도움이됩니다.
비트 맵 필터링이 포함 된 실행 계획을 분석 할 때는 계획을 통해 데이터가 흐르는 방식과 필터링이 적용되는 위치를 이해해야합니다. 비트 맵 필터와 최적화 된 비트 맵은 해시 조인의 빌드 입력 (차원 테이블)쪽에 만들어집니다. 그러나 실제 필터링은 일반적으로 해시 조인의 프로브 입력 (사실 테이블)에있는 Parallelism 연산자 내에서 수행됩니다. 그러나 비트 맵 필터가 정수 열을 기반으로하는 경우 병렬 처리 연산자가 아닌 초기 테이블 또는 인덱스 스캔 작업에 직접 필터를 적용 할 수 있습니다. 이 기술을 행 내 최적화라고합니다.
나는 그것이 당신이 당신의 쿼리로 관찰하고 있다고 생각합니다. 비트 맵 연산자가 IN_ROW팩트 테이블에 대한 경우에도 카디널리티 추정을 줄이는 재 파티셔닝 스트림 연산자를 보여주기 위해 비교적 간단한 데모를 만들 수 있습니다. 데이터 준비 :
create table outer_tbl (ID BIGINT NOT NULL);
INSERT INTO outer_tbl WITH (TABLOCK)
SELECT TOP (1000) ROW_NUMBER() OVER (ORDER BY (SELECT NULL))
FROM master..spt_values;
create table inner_tbl_1 (ID BIGINT NULL);
create table inner_tbl_2 (ID BIGINT NULL);
INSERT INTO inner_tbl_1 WITH (TABLOCK)
SELECT (ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) / 2000000 - 2) NUM
FROM master..spt_values t1
CROSS JOIN master..spt_values t2;
INSERT INTO inner_tbl_2 WITH (TABLOCK)
SELECT (ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) / 2000000 - 2) NUM
FROM master..spt_values t1
CROSS JOIN master..spt_values t2;
실행하지 말아야 할 쿼리는 다음과 같습니다.
SELECT *
FROM outer_tbl o
INNER JOIN inner_tbl_1 i ON o.ID = i.ID
INNER JOIN inner_tbl_2 i2 ON o.ID = i2.ID
OPTION (HASH JOIN, QUERYTRACEON 9481, QUERYTRACEON 8649);
나는 계획을 업로드했다 . 근처의 연산자를 살펴보십시오 inner_tbl_2.
Paul White의 Nullable Columns의 해시 조인에서 두 번째 테스트가 도움 이 될 수도 있습니다.
행 축소가 적용되는 방식에 일부 불일치가 있습니다. 나는 적어도 세 개의 테이블이있는 계획에서만 볼 수있었습니다. 그러나 올바른 데이터 분배를 통해 예상되는 행의 감소는 합리적입니다. 팩트 테이블의 조인 된 열에 차원 테이블에없는 많은 반복 된 값이 있다고 가정합니다. 비트 맵 필터는 조인에 도달하기 전에 해당 행을 제거 할 수 있습니다. 쿼리의 경우 추정치는 1로 줄어 듭니다. 해시 함수 사이에 행이 분산되는 방법은 좋은 힌트를 제공합니다.
이를 바탕으로 Object1.Column21열에 대해 반복되는 값이 많이 있다고 생각합니다 . 반복 열이 통계 히스토그램에없는 Object4.Column19경우 SQL Server는 카디널리티 예상치를 매우 잘못 얻을 수 있습니다.
쿼리 성능을 향상시킬 수 있다는 점에 대해 걱정해야한다고 생각합니다. 물론 쿼리가 응답 시간 또는 SLA 요구 사항을 충족하면 추가 조사 할 가치가 없습니다. 그러나 더 자세히 조사하려면 통계를 업데이트하는 것 외에 수행 할 수있는 몇 가지 방법으로 쿼리 최적화 프로그램이 더 나은 정보가있는 경우 더 나은 계획을 선택할 수 있는지에 대한 아이디어를 얻을 수 있습니다. (가) 간의 조인의 당신은 결과를 넣을 수 Database1.Schema1.Object10및 Database1.Schema1.Object11임시 테이블에 당신이 중첩 루프 조인가 계속되는지 확인합니다. LEFT OUTER JOIN쿼리 최적화 프로그램이 해당 단계의 행 수를 줄이지 않도록 조인을 변경할 수 있습니다 . MAXDOP 1쿼리에 힌트를 추가하여 어떤 일이 발생하는지 확인할 수 있습니다 . 당신은 사용할 수 있습니다TOP파생 테이블과 함께 조인을 마지막으로 강제 실행하거나 쿼리에서 조인을 주석 처리 할 수도 있습니다. 이 제안들이 당신을 시작하기에 충분하기를 바랍니다.
질문 의 연결 항목 과 관련하여 질문과 관련이있을 가능성은 거의 없습니다. 이 문제는 열 행 추정치와 관련이 없습니다. 병렬 처리의 경쟁 조건과 관련이 있어야하므로 뒤에서 쿼리 계획에서 너무 많은 행이 처리됩니다. 쿼리에서 추가 작업을 수행하지 않는 것 같습니다.
