인텔리전트 쿼리 처리 기능 세부 정보

아티클
01/21/2024

적용 대상:SQL Server Azure SQL DatabaseAzure SQL Managed Instance

이 문서에는 다양한 IQP(지능형 쿼리 처리) 기능, 릴리스 정보 및 자세한 내용에 대한 자세한 설명이 포함되어 있습니다. IQP(지능형 쿼리 처리) 기능 제품군에는 채택을 위한 최소한의 구현 노력으로 기존 워크로드의 성능을 향상시키는 광범위한 영향을 주는 기능이 포함되어 있습니다.

데이터베이스에 적용 가능한 데이터베이스 호환성 수준을 사용하도록 설정하여 워크로드를 지능형 쿼리 처리에 자동으로 적합하게 만들 수 있습니다. Transact-SQL을 사용하여 설정할 수 있습니다. 예를 들어 데이터베이스의 호환성 수준을 SQL Server 2022(16.x)로 설정하려면 다음을 실행합니다.

ALTER DATABASE [WideWorldImportersDW] SET COMPATIBILITY_LEVEL = 160;

모든 IQP 기능은 각 데이터베이스의 호환성 모드에 따라 Azure SQL Managed Instance 및 Azure SQL Database에서 사용할 수 있습니다. 새 버전에서 도입된 변경 내용에 대한 자세한 내용은 다음을 참조하세요.

일괄 처리 모드 적응 조인

적용 대상: SQL Server(SQL Server 2017(14.x)부터), Azure SQL Database

일괄 처리 모드 적응 조인 기능을 사용하면 캐시된 단일 계획을 사용하여 첫 번째 입력이 검사될 때까지 해시 조인 또는 중첩 루프 조인 메서드를 선택할 수 있습니다. 적응 조인 연산자는 중첩 루프 계획으로 전환할 시기를 결정하는 데 사용되는 임계값을 정의합니다. 따라서 계획을 실행하는 동안 더 나은 조인 전략으로 동적으로 전환할 수 있습니다.

호환성 수준을 변경하지 않고 적응 조인을 사용하지 않도록 설정하는 방법을 비롯한 자세한 내용은 적응 조인 이해를 참조 하세요.

MSTVF에 대한 인터리브 실행

적용 대상: SQL Server(SQL Server 2017(14.x)부터), Azure SQL Database

MSTVF(다중 문 테이블 반환 함수)는 매개 변수를 수락하고 RETURN 여러 T-SQL 문을 실행하고 테이블을 실행할 수 있는 사용자 정의 함수의 형식입니다.

인터리브 실행은 MSTVF와 관련된 고정된 카드의 예측으로 인한 워크로드 성능 문제를 지원합니다. 인터리브 실행을 사용하면 함수의 실제 행 개수가 더 나은 정보를 바탕으로 다운스트림 쿼리 계획 결정을 내리는 데 사용됩니다.

MSTVF에는 SQL Server 2014(12.x)부터 100, 이전 SQL Server 버전에 대해 1의 고정된 카드진수 추측이 있습니다.

인터리브 실행은 단일 쿼리 실행에 대한 최적화 및 실행 단계 간의 단방향 경계를 변경하고 수정된 카드 예측값에 따라 계획을 조정할 수 있도록 합니다. 데이터베이스 엔진이 MSTVF(다중 문 테이블 반환 함수)를 사용하는 인터리브 실행 후보가 발견되면 최적화가 일시 중지되고, 적용 가능한 하위 트리를 실행하고, 정확한 카드진수 예상치를 캡처한 다음 다운스트림 작업에 대한 최적화를 다시 시작합니다.

다음 이미지에서는 MSTVF의 고정 카디널리티 예상치에 따른 영향을 보여주는 전체 실행 계획의 하위 집합인 활성 쿼리 통계 출력을 보여줍니다.

실제 행 흐름 및 예상 행 수를 확인할 수 있습니다. 계획의 세 가지 중요한 영역이 있습니다(흐름은 오른쪽에서 왼쪽으로).

MSTVF 테이블 검색에는 100개의 행이 고정되어 있습니다. 그러나 이 예제의 경우 실제 예상 100개의 527597 통해 라이브 쿼리 통계에서 볼 수 있듯이 이 MSTVF 테이블 검색을 통해 527,597개의 행이 흐르므로 고정 예상치가 크게 왜곡됩니다.
중첩 루프 작업의 경우 조인의 외부 쪽에서 100개의 행만 반환되는 것으로 간주됩니다. 실제로 MSTVF에서 반환되는 많은 행 개수를 고려할 때 다른 조인 알고리즘을 사용하는 것이 나을 수도 있습니다.
해시 일치 작업의 경우 작은 경고 기호를 확인합니다. 이 경우 디스크에 대한 유출을 나타냅니다.

인터리브 실행을 사용하도록 설정된 실제 계획과 이전 계획을 대조합니다.

이제 MSTVF 테이블 검색은 정확한 카드 예측값을 반영합니다. 또한 이 테이블 검색 및 기타 작업의 순서를 다시 지정합니다.
조인 알고리즘과 관련하여 중첩 루프 작업에서 해시 일치 작업으로 전환했습니다. 이 작업은 관련된 행 수가 많을수록 더 적합합니다.
또한 MSTVF 테이블 검색에서 흐르는 실제 행 수에 따라 더 많은 메모리를 부여하므로 더 이상 유출 경고가 없습니다.

인터리브 실행 적합한 문

인터리브 실행의 MSTVF 참조 문은 현재 데이터 수정 작업의 일부가 아니라 읽기 전용이어야 합니다. 또한 MSTVF는 런타임 상수는 사용하지 않는 경우 인터리브된 실행에 적합하지 않습니다.

인터리브 실행 이점

일반적으로 예상 행 수와 실제 행 수 간의 오차가 높을수록 다운스트림 계획 작업 수와 함께 성능에 더 큰 영향을 줍니다.

일반적으로 인터리브 실행은 다음과 같은 쿼리에 도움이 됩니다.

중간 결과 집합의 예상 행 수와 실제 행 수 사이에는 큰 오차가 있습니다(이 경우 MSTVF).
또한 전체 쿼리는 중간 결과의 크기 변경에 민감합니다. 일반적으로 쿼리 계획에 해당 하위 트리 위에 복잡한 트리가 있을 때 발생합니다. MSTVF의 간단한 SELECT * 작업은 인터리브 실행의 이점을 얻을 수 없습니다.

인터리브 실행 오버헤드

오버헤드는 최소에서 없음이어야 합니다. 인터리브 실행이 도입되기 전에 MSTVF가 이미 구체화되었지만, 차이점은 이제 지연된 최적화를 허용하고 구체화된 행 집합의 카드 예측값을 사용한다는 점입니다. 변경에 영향을 주는 모든 계획과 마찬가지로 일부 계획은 하위 트리에 대한 더 나은 카드 가용성을 통해 전반적으로 쿼리에 대한 더 나쁜 계획을 얻을 수 있도록 변경할 수 있습니다. 완화에는 호환성 수준 되돌리기 또는 쿼리 저장소 사용하여 요금제의 회귀되지 않은 버전을 강제로 적용하는 것이 포함될 수 있습니다.

인터리브 실행 및 연속 실행

인터리브 실행 계획이 캐시되면 첫 번째 실행에서 수정된 예상값을 가진 계획이 인터리브 실행을 다시 시작하지 않고 연속 실행에 사용됩니다.

인터리브 실행 작업 추적

실제 쿼리 실행 계획에서 사용 특성을 볼 수 있습니다.

실행 계획 특성	설명
ContainsInterleavedExecutionCandidates	QueryPlan 노드에 적용됩니다. true이면 계획에 인터리브 실행 후보가 포함되어 있습니다.
IsInterleavedExecuted	TVF 노드에 대한 RelOp 아래에 있는 RuntimeInformation 요소의 특성입니다. true이면 연산이 인터리브 실행 작업의 일부로 구체화되었음을 의미합니다.

다음 확장 이벤트를 통해 인터리브 실행 발생을 추적할 수도 있습니다.

Xevent	설명
`interleaved_exec_status`	이 이벤트는 인터리브 실행이 발생할 때 발생합니다.
`interleaved_exec_stats_update`	이 이벤트는 인터리브 실행으로 업데이트된 카드 예측값을 설명합니다.
`Interleaved_exec_disabled_reason`	이 이벤트는 인터리브 실행의 가능한 후보가 있는 쿼리가 실제로 인터리브 실행을 얻지 못할 때 발생합니다.

인터리브 실행이 MSTVF 카드진수 예상치를 수정할 수 있도록 쿼리를 실행해야 합니다. 그러나 예상 실행 계획은 실행 계획 특성을 통해 ContainsInterleavedExecutionCandidates 인터리브 실행 후보가 있는 경우에도 계속 표시됩니다.

인터리브 실행 캐싱

캐시에서 계획을 지우거나 제거한 경우 쿼리 실행 시 인터리브 실행을 사용하는 새 컴파일이 있습니다. 사용하는 OPTION (RECOMPILE) 문은 인터리브 실행을 사용하여 새 계획을 만들고 캐시하지 않습니다.

인터리브 실행 및 쿼리 저장소 상호 운용성

인터리브 실행을 사용하는 계획은 강제 적용할 수 있습니다. 계획은 초기 실행에 따라 카디널리티 예상치를 수정한 버전입니다.

호환성 수준을 변경하지 않고 인터리브 실행 사용 안 함

데이터베이스 호환성 수준 140 이상을 기본 동안 데이터베이스 또는 문 범위에서 인터리브 실행을 사용하지 않도록 설정할 수 있습니다. 데이터베이스에서 시작된 모든 쿼리 실행에 대해 인터리브 실행을 사용하지 않도록 설정하려면 해당 데이터베이스의 컨텍스트 내에서 다음을 실행합니다.

-- SQL Server 2017
ALTER DATABASE SCOPED CONFIGURATION SET DISABLE_INTERLEAVED_EXECUTION_TVF = ON;

-- Starting with SQL Server 2019, and in Azure SQL Database
ALTER DATABASE SCOPED CONFIGURATION SET INTERLEAVED_EXECUTION_TVF = OFF;

사용하도록 설정하면 이 설정이 sys.database_scoped_configurations 활성화된 것으로 표시됩니다. 데이터베이스에서 시작된 모든 쿼리 실행에 대해 인터리브 실행을 다시 사용하도록 설정하려면 해당 데이터베이스의 컨텍스트 내에서 다음을 실행합니다.

-- SQL Server 2017
ALTER DATABASE SCOPED CONFIGURATION SET DISABLE_INTERLEAVED_EXECUTION_TVF = OFF;

-- Starting with SQL Server 2019, and in Azure SQL Database
ALTER DATABASE SCOPED CONFIGURATION SET INTERLEAVED_EXECUTION_TVF = ON;

USE HINT 쿼리 힌트로 지정하여 DISABLE_INTERLEAVED_EXECUTION_TVF 특정 쿼리에 대해 인터리브 실행을 사용하지 않도록 설정할 수도 있습니다. 예시:

SELECT [fo].[Order Key], [fo].[Quantity], [foo].[OutlierEventQuantity]
FROM [Fact].[Order] AS [fo]
INNER JOIN [Fact].[WhatIfOutlierEventQuantity]('Mild Recession',
                            '1-01-2013',
                            '10-15-2014') AS [foo] ON [fo].[Order Key] = [foo].[Order Key]
                            AND [fo].[City Key] = [foo].[City Key]
                            AND [fo].[Customer Key] = [foo].[Customer Key]
                            AND [fo].[Stock Item Key] = [foo].[Stock Item Key]
                            AND [fo].[Order Date Key] = [foo].[Order Date Key]
                            AND [fo].[Picked Date Key] = [foo].[Picked Date Key]
                            AND [fo].[Salesperson Key] = [foo].[Salesperson Key]
                            AND [fo].[Picker Key] = [foo].[Picker Key]
OPTION (USE HINT('DISABLE_INTERLEAVED_EXECUTION_TVF'));

USE HINT 쿼리 힌트는 데이터베이스 범위 구성 또는 추적 플래그 설정보다 우선합니다.

스칼라 UDF 인라인 처리

적용 대상: SQL Server(SQL Server 2019(15.x)부터), Azure SQL Database

스칼라 UDF 인라인 처리는 스칼라 UDF를 관계형 식으로 자동으로 변환합니다. 호출 SQL 쿼리에 포함됩니다. 이 변환은 스칼라 UDF를 활용하는 워크로드의 성능을 개선합니다. 스칼라 UDF 인라인 처리는 UDF 내부에서 작업의 비용 기반 최적화를 이용합니다. 비효율적이고 반복적인 직렬 실행 계획 대신에, 효율적인 세트 지향 병렬 실행 계획이 생성됩니다. 이 기능은 기본적으로 데이터베이스 호환성 수준 150 이상에서 사용하도록 설정됩니다.

자세한 내용은 스칼라 UDF 인라인을 참조 하세요.

테이블 변수 지연 컴파일

적용 대상: SQL Server(SQL Server 2019(15.x)부터), Azure SQL Database

테이블 변수 지연 컴파일 은 테이블 변수를 참조하는 쿼리에 대한 계획 품질 및 전반적인 성능을 향상시킵니다. 최적화 및 초기 계획 컴파일 중에 이 기능은 실제 테이블 변수 행 수를 기반으로 하는 카드 예측값을 전파합니다. 그러면 이 정확한 행 개수 정보가 다운스트림 계획 작업을 최적화하는 데 사용됩니다.

테이블 변수 지연 컴파일을 사용하면 테이블 변수를 참조하는 문의 컴파일이 문의 첫 번째 실제 실행까지 지연됩니다. 이 지연된 컴파일 동작은 임시 테이블의 동작과 동일합니다. 이렇게 변경하면 원래 한 행 추측 대신 실제 카드inality가 사용됩니다.

테이블 변수 지연 컴파일을 사용하도록 설정하려면 쿼리가 실행될 때 연결된 데이터베이스에 대해 데이터베이스 호환성 수준 150 이상을 사용하도록 설정합니다.

테이블 변수 지연 컴파일 은 테이블 변수의 다른 특성을 변경하지 않습니다 . 예를 들어 이 기능은 테이블 변수에 열 통계를 추가하지 않습니다.

테이블 변수 지연 컴파일 은 다시 컴파일 빈도를 증가시키지 않습니다. 대신 초기 컴파일이 발생하는 위치로 이동합니다. 그 결과로 캐시된 계획은 초기 지연 컴파일 테이블 변수 행 개수를 기반으로 생성됩니다. 캐시된 계획은 연속 쿼리에서 다시 사용됩니다. 계획이 제거되거나 다시 컴파일될 때까지 다시 사용됩니다.

초기 계획 컴파일에 사용되는 테이블 변수 행 수는 일반적인 값이 고정 행 개수 추측과 다를 수 있음을 나타냅니다. 이러한 행 개수가 다른 경우 다운스트림 작업에 도움이 됩니다. 테이블 변수 행 수가 실행에 따라 크게 달라지는 경우 이 기능으로 성능이 향상되지 않을 수 있습니다.

호환성 수준을 변경하지 않고 테이블 변수 지연 컴파일 사용 안 함

데이터베이스 호환성 수준 150 이상을 기본 동안 데이터베이스 또는 문 범위에서 테이블 변수 지연 컴파일을 사용하지 않도록 설정합니다. 데이터베이스에서 시작된 모든 쿼리 실행에 대해 테이블 변수 지연 컴파일을 사용하지 않도록 설정하려면 해당 데이터베이스의 컨텍스트 내에서 다음 예제를 실행합니다.

ALTER DATABASE SCOPED CONFIGURATION SET DEFERRED_COMPILATION_TV = OFF;

데이터베이스에서 시작된 모든 쿼리 실행에 대해 테이블 변수 지연 컴파일을 다시 사용하도록 설정하려면 해당 데이터베이스의 컨텍스트 내에서 다음 예제를 실행합니다.

ALTER DATABASE SCOPED CONFIGURATION SET DEFERRED_COMPILATION_TV = ON;

DISABLE_DEFERRED_COMPILATION_TV USE HINT 쿼리 힌트로 할당하여 특정 쿼리에 대해 테이블 변수 지연 컴파일을 사용하지 않도록 설정할 수도 있습니다. 예시:

DECLARE @LINEITEMS TABLE 
    (L_OrderKey INT NOT NULL,
     L_Quantity INT NOT NULL
    );

INSERT @LINEITEMS
SELECT L_OrderKey, L_Quantity
FROM dbo.lineitem
WHERE L_Quantity = 5;

SELECT O_OrderKey,
    O_CustKey,
    O_OrderStatus,
    L_QUANTITY
FROM    
    ORDERS,
    @LINEITEMS
WHERE    O_ORDERKEY    =    L_ORDERKEY
    AND O_OrderStatus = 'O'
OPTION (USE HINT('DISABLE_DEFERRED_COMPILATION_TV'));

매개 변수 민감도 계획 최적화

적용 대상: SQL Server(SQL Server 2022(16.x)부터)

PSP(매개 변수 민감도 계획) 최적화는 지능형 쿼리 처리 기능 제품군의 일부입니다. 매개 변수가 있는 쿼리에 대해 캐시된 단일 계획이 가능한 모든 들어오는 매개 변수 값에 최적이 아닌 시나리오를 해결합니다. 이는 비유니폼 데이터 배포의 경우입니다.

PSP 최적화에 대한 자세한 내용은 매개 변수 중요한 계획 최적화를 참조 하세요.
매개 변수화 및 매개 변수 민감도에 대한 자세한 내용은 매개 변수 민감도 및 매개 변수 및 실행 계획 재사용을 참조하세요.

대략적 쿼리 처리

대략적인 쿼리 처리는 새로운 기능 제품군입니다. 응답성이 절대 정밀도보다 중요한 대규모 데이터 세트 전반에 걸쳐 집계됩니다. 예를 들어 대시보드에 표시하기 COUNT(DISTINCT()) 위해 100억 개의 행을 계산합니다. 이 경우 절대 정밀도는 중요하지 않지만 응답성은 중요합니다.

대략적인 Count Distinct

적용 대상: SQL Server(SQL Server 2019(15.x)부터), Azure SQL Database

새 APPROX_COUNT_DISTINCT 집계 함수는 그룹의 null이 아닌 고유 값의 대략적인 수를 반환합니다.

이 기능은 호환성 수준에 관계없이 SQL Server 2019(15.x)부터 사용할 수 있습니다.

자세한 내용은 APPROX_COUNT_DISTINCT(Transact-SQL)를 참조 하세요.

근사 백분위수

적용 대상: SQL Server(SQL Server 2022(16.x)부터), Azure SQL Database

이러한 집계 함수는 대략적인 백분위수 집계 함수를 사용하여 신속한 의사 결정을 내릴 수 있도록 허용 가능한 순위 기반 오류 범위가 있는 큰 데이터 세트에 대한 백분위수 계산

자세한 내용은 APPROX_PERCENTILE_DISC(Transact-SQL) 및 APPROX_PERCENTILE_CONT(Transact-SQL)를 참조하세요.

rowstore의 일괄 처리 모드

적용 대상: SQL Server(SQL Server 2019(15.x)부터), Azure SQL Database

rowstore의 일괄 처리 모드는 columnstore 인덱스를 요구하지 않고도 분석 워크로드에 대한 일괄 처리 모드를 실행할 수 있습니다. 이 기능은 디스크 힙 및 B-트리 인덱스에 대한 일괄 처리 모드 실행 및 비트맵 필터를 지원합니다. rowstore의 일괄 처리 모드는 기존의 모든 일괄 처리 모드 지원 연산자를 지원할 수 있습니다.

참고 항목

SQL Server 설명서는 인덱스를 지칭할 때 B-트리라는 용어를 사용합니다. rowstore 인덱스에서 SQL Server는 B+ 트리를 구현합니다. 이는 columnstore 인덱스나 메모리 내 데이터 저장소에는 적용되지 않습니다. 자세한 내용은 SQL Server 및 Azure SQL 인덱스 아키텍처 및 디자인 가이드를 참조 하세요.

일괄 처리 모드 실행 개요

SQL Server 2012(11.x)는 분석 워크로드를 가속화하는 새로운 기능인 columnstore 인덱스를 도입했습니다. 이후 SQL Server 릴리스마다 columnstore 인덱스의 사용 사례 및 성능이 증가했습니다. 테이블에 columnstore 인덱스를 만들면 분석 워크로드의 성능이 향상될 수 있습니다. 그러나 다음과 같은 두 가지 관련 있지만 고유한 기술 집합이 있습니다.

columnstore 인덱스를 사용하면 분석 쿼리는 필요한 열의 데이터만 액세스합니다. columnstore 형식의 페이지 압축은 기존 rowstore 인덱스의 압축보다 더 효과적입니다.
일괄 처리 모드 처리를 사용하면 쿼리 연산자가 데이터를 보다 효율적으로 처리합니다. 이 연산자는 한 번에 하나의 행이 아니라 행 일괄 처리에서 작동합니다. 다른 많은 확장성 향상은 일괄 처리 모드 처리와 관련이 있습니다. 일괄 처리 모드에 대한 자세한 내용은 실행 모드를 참조 하세요.

두 기능 집합이 함께 작동하여 입력/출력(I/O) 및 CPU 사용률을 향상시킵니다.

columnstore 인덱스를 사용하면 더 많은 데이터가 메모리에 적합합니다. 이렇게 하면 I/O 워크로드가 줄어듭니다.
일괄 처리 모드는 CPU를 보다 효율적으로 사용합니다.

두 기술은 가능할 때마다 서로를 활용합니다. 예를 들어, 일괄 처리 모드 집계를 columnstore 인덱스 검색의 일부로 평가할 수 있습니다. 또한 압축된 columnstore 데이터는 일괄 처리 모드 조인 및 일괄 처리 모드 집계를 통해 훨씬 더 효율적으로 실행 길이 인코딩을 사용하여 처리됩니다.

그러나 두 기능은 독립적이라는 것을 이해하는 것이 중요합니다.

columnstore 인덱스를 사용하는 행 모드 계획을 가져올 수 있습니다.
rowstore 인덱스만 사용하는 일괄 처리 모드 계획을 가져올 수 있습니다.

일반적으로 두 기능을 함께 사용하면 최상의 결과를 얻을 수 있습니다. SQL Server 2019(15.x) 이전에는 SQL Server 쿼리 최적화 프로그램에서 columnstore 인덱스가 있는 테이블이 하나 이상 포함된 쿼리에 대해서만 일괄 처리 모드를 고려했습니다.

Columnstore 인덱스는 일부 애플리케이션에 적합하지 않을 수 있습니다. 애플리케이션은 columnstore 인덱스로 지원되지 않는 다른 기능을 사용할 수 있습니다. 예를 들어 현재 위치 수정은 columnstore 압축과 호환되지 않습니다. 따라서 클러스터형 columnstore 인덱스가 있는 테이블에서는 트리거가 지원되지 않습니다. 무엇보다도 columnstore 인덱스는 DELETE 및 UPDATE 문에 대한 오버헤드를 추가합니다.

일부 하이브리드 트랜잭션 분석 워크로드의 경우 트랜잭션 워크로드의 오버헤드가 columnstore 인덱스를 사용하여 얻은 이점보다 큽니다. 해당 시나리오는 일괄 처리 모드 처리만 채택하여 개선된 CPU 사용량을 활용할 수 있습니다. 따라서 batch-mode-on-rowstore 기능은 관련된 인덱스 유형에 관계없이 모든 쿼리에 대한 일괄 처리 모드를 고려합니다.

rowstore의 일괄 처리 모드를 활용할 수 있는 워크로드

다음 워크로드는 rowstore의 일괄 처리 모드를 활용할 수 있습니다.

워크로드의 중요한 부분은 분석 쿼리로 구성됩니다. 일반적으로 이러한 쿼리는 수십만 개 이상의 행을 처리하는 조인 또는 집계와 같은 연산자를 사용합니다.
워크로드가 CPU 바인딩되어 있습니다. 병목 현상이 I/O인 경우 가능한 경우 columnstore 인덱스도 고려하는 것이 좋습니다.
columnstore 인덱스 만들기는 워크로드의 트랜잭션 부분에 너무 많은 오버헤드를 추가합니다. 또는 애플리케이션이 columnstore 인덱스로 아직 지원되지 않는 기능에 따라 달라지므로 columnstore 인덱스를 만들 수 없습니다.

참고 항목

rowstore의 일괄 처리 모드는 CPU 사용량을 줄이는 데에만 도움이 됩니다. 병목 상태가 I/O 관련이고 데이터가 아직 캐시되지 않은 경우("콜드" 캐시), rowstore의 일괄 처리 모드는 쿼리 경과 시간을 개선하지 않습니다. 마찬가지로 컴퓨터에 모든 데이터를 캐시할 충분한 메모리가 없으면 성능이 향상될 가능성이 낮습니다.

rowstore에서 일괄 처리 모드로 변경되는 사항은 무엇인가요?

rowstore의 일괄 처리 모드를 사용하려면 데이터베이스가 호환성 수준 150이어야 합니다.

쿼리가 columnstore 인덱스가 있는 테이블에 액세스하지 않더라도 쿼리 프로세서는 추론을 사용하여 일괄 처리 모드를 고려할지 여부를 결정합니다. 추론은 다음 검사 구성됩니다.

입력 쿼리에서 테이블 크기, 사용된 연산자 및 예상 카드 검사.
최적화 프로그램이 쿼리에 대한 더 저렴한 새 계획을 발견함에 따라 추가 검사포인트입니다. 이 대체 계획이 일괄 처리 모드를 충분히 사용하지 않을 경우 최적화 프로그램은 일괄 처리 모드의 대안을 더 이상 검색하지 않습니다.

rowstore에서 일괄 처리 모드가 사용되는 경우에는 쿼리 계획에서 실제 실행 모드가 일괄 처리 모드로 표시됩니다. 검사 연산자는 디스크 내 힙 및 B-트리 인덱스에 일괄 처리 모드를 사용합니다. 이 일괄 처리 모드 검사는 일괄 처리 모드 비트맵 필터를 평가할 수 있습니다. 계획에 다른 일괄 처리 모드 연산자가 표시될 수도 있습니다. 예를 들어 해시 조인, 해시 기반 집계, 정렬, 창 집계, 필터, 연결 및 컴퓨팅 스칼라 연산자가 있습니다.

설명

쿼리 계획에서 항상 일괄 처리 모드를 사용하는 것은 아닙니다. 쿼리 최적화 프로그램에서 일괄 처리 모드가 쿼리에 적합하지 않다고 결정할 수 있습니다.

쿼리 최적화 프로그램의 검색 공간이 변경되고 있습니다. 따라서 행 모드 계획을 가져오는 경우 낮은 호환성 수준에서 얻는 계획과 동일하지 않을 수 있습니다. 일괄 처리 모드 계획을 가져오는 경우 columnstore 인덱스로 가져오는 계획과 같지 않을 수 있습니다.

새 일괄 처리 모드 rowstore 검사로 인해 columnstore 및 rowstore 인덱스를 혼합하는 쿼리에 대한 계획도 변경될 수 있습니다.

rowstore 검사의 새 일괄 처리 모드에는 현재 제한 사항이 있습니다.

메모리 내 OLTP 테이블 또는 디스크에 있는 힙 및 B-트리 이외의 인덱스에는 이러한 제한이 적용되지 않습니다.
또한 LOB(큰 개체) 열을 가져오거나 필터링하는 경우에도 시작되지 않습니다. 이 제한 사항에는 스파스 열 집합 및 XML 열이 포함됩니다.

일괄 처리 모드가 columnstore 인덱스와 함께 사용되지 않는 쿼리가 있습니다. 예를 들어 커서가 포함된 쿼리입니다. rowstore의 일괄 처리 모드에도 이 제외가 동일하게 적용됩니다.

rowstore에서 일괄 처리 모드 구성

데이터베이스 범위 구성은 BATCH_MODE_ON_ROWSTORE기본적으로 ON입니다.

데이터베이스 호환성 수준을 변경하지 않고 rowstore에서 일괄 처리 모드를 사용하지 않도록 설정할 수 있습니다.

-- Disabling batch mode on rowstore
ALTER DATABASE SCOPED CONFIGURATION SET BATCH_MODE_ON_ROWSTORE = OFF;

-- Enabling batch mode on rowstore
ALTER DATABASE SCOPED CONFIGURATION SET BATCH_MODE_ON_ROWSTORE = ON;

데이터베이스 범위 구성을 통해 rowstore에서 일괄 처리 모드를 사용하지 않도록 설정할 수 있습니다. 하지만 쿼리 힌트를 사용하여 쿼리 수준에서 설정을 재정의할 ALLOW_BATCH_MODE 수 있습니다. 다음 예제에서는 데이터베이스 범위 구성을 통해 기능이 비활성화된 경우에도 rowstore에서 일괄 처리 모드를 사용하도록 설정합니다.

SELECT [Tax Rate], [Lineage Key], [Salesperson Key], SUM(Quantity) AS SUM_QTY, SUM([Unit Price]) AS SUM_BASE_PRICE, COUNT(*) AS COUNT_ORDER
FROM Fact.OrderHistoryExtended
WHERE [Order Date Key]<=DATEADD(dd, -73, '2015-11-13')
GROUP BY [Tax Rate], [Lineage Key], [Salesperson Key]
ORDER BY [Tax Rate], [Lineage Key], [Salesperson Key]
OPTION(RECOMPILE, USE HINT('ALLOW_BATCH_MODE'));

쿼리 힌트를 사용하여 특정 쿼리에 대해 rowstore에서 일괄 처리 모드를 DISALLOW_BATCH_MODE 사용하지 않도록 설정할 수도 있습니다. 다음 예제를 참조하십시오.

SELECT [Tax Rate], [Lineage Key], [Salesperson Key], SUM(Quantity) AS SUM_QTY, SUM([Unit Price]) AS SUM_BASE_PRICE, COUNT(*) AS COUNT_ORDER
FROM Fact.OrderHistoryExtended
WHERE [Order Date Key]<=DATEADD(dd, -73, '2015-11-13')
GROUP BY [Tax Rate], [Lineage Key], [Salesperson Key]
ORDER BY [Tax Rate], [Lineage Key], [Salesperson Key]
OPTION(RECOMPILE, USE HINT('DISALLOW_BATCH_MODE'));

쿼리 처리 피드백 기능

쿼리 처리 피드백 기능은 지능형 쿼리 처리 기능 제품군의 일부입니다.

쿼리 처리 피드백은 SQL Server, Azure SQL Database 및 Azure SQL Managed Instance의 쿼리 프로세서가 쿼리 실행에 대한 기록 데이터를 사용하여 쿼리가 컴파일 및 실행 방식에 대한 하나 이상의 변경 내용으로부터 도움을 받을 수 있는지 여부를 결정하는 프로세스입니다. 성능 데이터는 쿼리 저장소에서 수집되며 쿼리 실행을 개선하기 위한 다양한 제안이 있습니다. 성공하면 나중에 사용할 수 있도록 메모리 및/또는 쿼리 저장소에서 디스크에 대한 이러한 수정 사항을 유지합니다. 제안이 충분히 개선되지 않으면 dis카드ed이고, 쿼리는 해당 피드백 없이 계속 실행됩니다.

SQL Server의 여러 릴리스 또는 Azure SQL Database 또는 Azure SQL Managed Instance에서 사용할 수 있는 쿼리 처리 피드백 기능에 대한 자세한 내용은 SQL 데이터베이스의 지능형 쿼리 처리 또는 각 피드백 기능에 대한 다음 문서를 참조하세요.

메모리 부여 피드백

메모리 부여 피드백은 지난 SQL Server의 주요 릴리스를 통해 웨이브에 도입되었습니다.

일괄 처리 모드 메모리 부여 피드백

Batch 모드 메모리 부여 피드백에 대한 자세한 내용은 Batch 모드 메모리 부여 피드백을 참조 하세요.

행 모드 메모리 부여 피드백

행 모드 메모리 부여 피드백에 대한 자세한 내용은 행 모드 메모리 부여 피드백을 참조 하세요.

백분위수 및 지속성 모드 메모리 부여 피드백

백분위수 및 지속성 모드 메모리 부여 피드백에 대한 자세한 내용은 백분위수 및 지속성 모드 메모리 부여 피드백을 참조 하세요.

DOP(병렬 처리 수준) 피드백

DOP 피드백에 대한 자세한 내용은 DOP(병렬 처리 수준) 피드백을 참조 하세요.

CE(카디널리티 추정) 피드백

CE 피드백에 대한 자세한 내용은 CE(카디널리티 추정) 피드백을 참조 하세요.

쿼리 저장소를 사용하여 최적화된 계획 강제 실행

쿼리 저장소 강제하는 최적화된 계획에 대한 자세한 내용은 쿼리 저장소 강제하는 최적화된 계획을 방문하세요.

인텔리전트 쿼리 처리 기능 세부 정보

일괄 처리 모드 적응 조인

MSTVF에 대한 인터리브 실행

인터리브 실행 적합한 문

인터리브 실행 이점

인터리브 실행 오버헤드

인터리브 실행 및 연속 실행

인터리브 실행 작업 추적

인터리브 실행 캐싱

인터리브 실행 및 쿼리 저장소 상호 운용성

호환성 수준을 변경하지 않고 인터리브 실행 사용 안 함

스칼라 UDF 인라인 처리

테이블 변수 지연 컴파일

호환성 수준을 변경하지 않고 테이블 변수 지연 컴파일 사용 안 함

매개 변수 민감도 계획 최적화

대략적 쿼리 처리

대략적인 Count Distinct

근사 백분위수

rowstore의 일괄 처리 모드

일괄 처리 모드 실행 개요

rowstore의 일괄 처리 모드를 활용할 수 있는 워크로드

rowstore에서 일괄 처리 모드로 변경되는 사항은 무엇인가요?

설명

rowstore에서 일괄 처리 모드 구성

쿼리 처리 피드백 기능

메모리 부여 피드백

일괄 처리 모드 메모리 부여 피드백

행 모드 메모리 부여 피드백

백분위수 및 지속성 모드 메모리 부여 피드백

DOP(병렬 처리 수준) 피드백

CE(카디널리티 추정) 피드백

쿼리 저장소를 사용하여 최적화된 계획 강제 실행

관련 콘텐츠

피드백

피드백

추가 리소스