지능형 쿼리 처리 기능 상세 설명
적용 대상: 
SQL Server Azure SQL 데이터베이스 Azure 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 데이터베이스에서 사용할 수 있습니다. 새 버전에서 도입된 변경 사항에 대한 자세한 내용은 다음을 참조하세요.
일괄 처리 모드 적응 조인
적용 대상: SQL Server(SQL Server 2017(14.x)부터 시작) 및 Azure SQL 데이터베이스
적응 조인 기능을 사용하면, 단일 캐시된 플랜을 통해 해시 조인 또는 중첩된 루프 조인 메서드 선택을 첫 번째 입력이 검사된 후까지 지연할 수 있습니다. 적응 조인 연산자는 중첩 루프 계획으로 전환할 시기를 결정하는 데 사용되는 임계값을 정의합니다. 따라서 계획을 실행하는 동안 더 나은 조인 전략으로 동적으로 전환할 수 있습니다.
호환성 수준을 변경하지 않고 적응 조인을 사용하지 않도록 설정하는 방법을 비롯한 자세한 내용은 적응 조인 이해를 참조하세요.
MSTVF의 인터리브 실행
적용 대상: SQL Server(SQL Server 2017(14.x)부터 시작) 및 Azure SQL 데이터베이스
MSTVF(다중 문 테이블 반환 함수)는 매개 변수를 수락하고 여러 T-SQL 문을 실행하고 테이블을 RETURN할 수 있는 사용자 정의 함수의 형식입니다.
인터리브 실행은 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에서 이 설정이 enabled로 표시됩니다. 데이터베이스에서 발생하는 모든 쿼리 실행에 대해 인터리브 실행을 다시 사용하지 않도록 설정하려면 해당 데이터베이스의 컨텍스트 내에서 다음을 실행합니다.
-- 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;
또한 DISABLE_INTERLEAVED_EXECUTION_TVF을 USE HINT 쿼리 힌트로 지정하여 특정 쿼리에 대한 인터리브 실행을 사용하지 않도록 설정할 수도 있습니다. 예시:
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 데이터베이스
스칼라 UDF 인라인 처리는 스칼라 UDF를 관계형 식으로 자동으로 변환합니다. 그리고 스칼라 UDF를 호출 SQL 쿼리에 포함합니다. 이 변환은 스칼라 UDF를 활용하는 워크로드의 성능을 개선합니다. 스칼라 UDF 인라인 처리는 UDF 내부에서 작업의 비용 기반 최적화를 이용합니다. 비효율적이고 반복적인 직렬 실행 계획 대신에, 효율적인 세트 지향 병렬 실행 계획이 생성됩니다. 이 기능은 데이터베이스 호환성 수준 150 이상에서 기본적으로 사용하도록 설정됩니다.
자세한 내용은 스칼라 UDF 인라인 처리를 참조하세요.
테이블 변수 지연 컴파일
적용 대상: SQL Server (SQL Server 2019(15.x)부터 시작), Azure SQL 데이터베이스
테이블 변수 지연 컴파일은 테이블 변수를 참조하는 쿼리의 계획 품질 및 전체 성능을 개선합니다. 최적화 및 초기 계획 컴파일 중에 이 기능은 실제 테이블 변수 행 수를 기반으로 하는 카디널리티 예측을 전파합니다. 그런 다음 이 정확한 행 수 정보가 다운스트림 계획 작업을 최적화하는 데 사용됩니다.
테이블 변수 지연 컴파일을 사용하면 테이블 변수를 참조하는 문의 컴파일이 문의 첫 번째 실제 실행까지 지연됩니다. 이 지연된 컴파일 동작은 임시 테이블의 동작과 동일합니다. 이렇게 변경하면 원래 한 행 추측 대신 실제 카디널리티가 사용됩니다.
테이블 변수 지연 컴파일을 사용하도록 설정하려면 쿼리가 실행될 때 연결된 데이터베이스의 데이터베이스 호환성 수준 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 최적화에 대한 자세한 내용은 매개 변수 중요 계획 최적화를 참조하세요.
- 매개 변수화 및 매개 변수 민감도에 대한 자세한 내용은 매개 변수 민감도와 매개 변수 및 실행 계획 재사용을 참조하세요.
대략적인 쿼리 처리
대략적인 쿼리 처리는 새로운 기능 제품군입니다. 절대적인 정밀도보다 응답성이 더 중요한 큰 데이터 집합을 기반으로 집계합니다. 예를 들어 대시보드에 표시하기 위해 100억 개 행을 기반으로 COUNT(DISTINCT())를 계산할 수 있습니다. 이 경우 절대 정밀도는 중요하지 않지만 응답성은 중요합니다.
대략적인 고유 개수
적용 대상: SQL Server (SQL Server 2019(15.x)부터 시작), Azure SQL 데이터베이스
새로운 APPROX_COUNT_DISTINCT 집계 합수는 그룹에 있는 고유한 null이 아닌 값의 대략적인 개수를 반환합니다.
이 기능은 호환성 수준에 관계없이 SQL Server 2019(15.x)부터 사용할 수 있습니다.
자세한 내용은 APPROX_COUNT_DISTINCT(Transact-SQL)를 참조하세요.
대략적인 백분위수
적용 대상: SQL Server(SQL Server 2022(16.x)부터) 및 Azure SQL 데이터베이스
이 집계 함수는 대략적인 백분위수 집계 함수를 사용하여 신속한 의사 결정을 내릴 수 있도록 허용 가능한 순위 기반 오류 범위가 있는 대규모 데이터 세트에 대한 백분위수를 계산합니다.
자세한 내용은 APPROX_PERCENTILE_DISC(Transact-SQL) 및 APPROX_PERCENTILE_CONT(Transact-SQL)를 참조하세요.
rowstore의 일괄 처리 모드
적용 대상: SQL Server (SQL Server 2019(15.x)부터 시작), Azure SQL 데이터베이스
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(Large Object) 열을 가져오거나 필터링하는 경우에도 실행되지 않습니다. 이 제한 사항에는 스파스 열 집합 및 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'));
또한 DISALLOW_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('DISALLOW_BATCH_MODE'));
쿼리 처리 피드백 기능
쿼리 처리 피드백 기능은 지능형 쿼리 처리 기능 세트의 일부입니다.
쿼리 처리 피드백은 SQL Server, Azure SQL 데이터베이스 및 Azure SQL Managed Instance의 쿼리 프로세서가 쿼리 실행에 대한 기록 데이터를 사용하여 쿼리가 컴파일 및 실행 방식에 대한 하나 이상의 변경 내용으로부터 도움을 받을 수 있는지 여부를 결정하는 프로세스입니다. 성능 데이터는 쿼리 저장소에서 수집되며 쿼리 실행을 개선하기 위한 다양한 제안이 있습니다. 성공하면 나중에 사용할 수 있도록 메모리 및/또는 쿼리 저장소에서 디스크에 대한 이러한 수정 사항을 유지합니다. 제안이 충분히 개선되지 않으면 삭제되고 쿼리는 해당 피드백 없이 계속 실행됩니다.
SQL Server의 여러 릴리스 또는 Azure SQL Database 또는 Azure SQL Managed Instance에서 사용할 수 있는 쿼리 처리 피드백 기능에 대한 자세한 내용은 SQL 데이터베이스의 지능형 쿼리 처리 또는 각 피드백 기능에 대한 다음 문서를 참조하세요.
메모리 부여 피드백
메모리 부여 피드백은 지난 SQL Server의 주요 릴리스를 통해 웨이브에 도입되었습니다.
일괄 처리 모드 메모리 부여 피드백
일괄 처리 모드 메모리 부여 피드백에 대한 자세한 내용은 일괄 처리 모드 메모리 부여 피드백을 참조하세요.
행 모드 메모리 부여 피드백
행 모드 메모리 부여 피드백에 대한 자세한 내용은 행 모드 메모리 부여 피드백을 참조하세요.
백분위수 및 지속성 모드 메모리 부여 피드백
백분위수 및 지속성 모드 메모리 부여 피드백에 대한 자세한 내용은 백분위수 및 지속성 모드 메모리 부여 피드백을 참조하세요.
DOP(병렬 처리 수준) 피드백
DOP 피드백에 대한 자세한 내용은 DOP(병렬 처리 수준) 피드백을 참조하세요.
CE(카디널리티 추정) 피드백
CE 피드백에 대한 자세한 내용은 CE(카디널리티 추정) 피드백을 참조하세요.
쿼리 저장소를 사용하여 최적화된 계획 강제 실행
쿼리 저장소 강제하는 최적화된 계획에 대한 자세한 내용은 쿼리 저장소 강제하는 최적화된 계획을 참조하세요.
관련 콘텐츠
- 조인(SQL Server)
- 실행 모드
- 쿼리 처리 아키텍처 가이드
- 실행 계획 논리 및 물리 연산자 참조
- ALTER DATABASE SCOPED CONFIGURATION(Transact-SQL)
- SQL Server 2017의 새로운 기능
- SQL Server 2019의 새로운 기능
- SQL Server 2022의 새로운 기능
- 지능형 쿼리 처리 시연
- 상수 폴딩 및 식 평가
- GitHub의 지능형 쿼리 처리 데모
- SQL Server 데이터베이스 엔진 및 Azure SQL Database용 성능 센터
- 쿼리 저장소를 사용하여 성능 모니터링
- 쿼리 저장소 사용한 워크로드 모니터링 모범 사례
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기