분할된 테이블 및 인덱스
적용 대상: 
SQL Server Azure SQL 데이터베이스 Azure SQL Managed Instance
SQL Server, Azure SQL 데이터베이스, Azure SQL Managed Instance는 테이블 및 인덱스 분할을 지원합니다. 분할된 테이블 및 인덱스의 데이터는 데이터베이스에서 둘 이상의 파일 그룹에 분산되는 단위로 나뉘거나 단일 파일 그룹에 저장됩니다. 파일 그룹에 여러 파일이 있는 경우 비례 채우기 알고리즘을 사용하여 데이터가 파일 전체에 분산됩니다. 행 그룹이 개별 파티션에 매핑되도록 데이터가 가로로 분할됩니다. 단일 인덱스 또는 테이블의 모든 파티션은 동일한 데이터베이스에 있어야 합니다. 데이터에서 쿼리나 업데이트가 수행되면 테이블이나 인덱스는 단일 논리적 엔터티로 처리됩니다.
SQL Server 2016(13.x) SP1 이전에는 모든 버전의 SQL Server에서 분할된 테이블 및 인덱스를 사용할 수 없었습니다. SQL Server 버전에서 지원되는 기능 목록은 SQL Server 2022의 버전과 지원하는 기능을 참조하세요. 분할된 테이블 및 인덱스는 Azure SQL 데이터베이스 및 Azure SQL Managed Instance의 모든 서비스 계층에서 사용할 수 있습니다.
테이블 분할은 몇 가지 구문 차이와 함께 Azure Synapse Analytics의 전용 SQL 풀에서도 사용할 수 있습니다. 자세한 내용은 전용 SQL 풀의 테이블 분할을 참조하세요.
Important
기본적으로 데이터베이스 엔진은 최대 15,000개의 파티션을 지원합니다. SQL Server 2012(11.x) 이전 버전에서는 파티션 수가 기본적으로 1,000개로 제한되었습니다.
분할의 이점
큰 테이블 또는 인덱스를 분할하면 다음과 같은 관리 효율성과 성능 이점이 있을 수 있습니다.
데이터 하위 집합을 빠르고 효율적으로 전송하거나 액세스할 수 있을 뿐만 아니라 데이터 컬렉션의 무결성을 유지할 수 있습니다. 예를 들어 OLTP에서 OLAP 시스템으로 데이터를 로드하는 등의 작업은 데이터가 분할되지 않을 때 작업에서 소요되는 분 및 시간 대신 몇 초밖에 걸리지 않습니다.
하나 이상의 파티션에서 유지 관리 또는 데이터 보존 작업을 더 빠르게 수행할 수 있습니다. 작업은 전체 테이블 대신 이러한 데이터 하위 집합만 대상으로 지정하기 때문에 더 효율적입니다. 예를 들어 하나 이상의 파티션에서 데이터를 압축하거나 인덱스의 파티션 중 하나 이상을 다시 작성하거나 단일 파티션에서 데이터를 자를 수 있습니다. 개별 파티션을 한 테이블에서 보관 테이블로 전환할 수도 있습니다.
자주 실행되는 쿼리 유형에 따라 쿼리 성능을 높일 수 있습니다. 예를 들어 쿼리 최적화 프로그램은 분할 열이 테이블이 조인된 열과 같을 때 둘 이상의 분할된 테이블 간에 동등 조인 쿼리를 더 빠르게 처리할 수 있습니다. 자세한 내용은 아래 쿼리를 참조하세요.
전체 테이블이 아니라 파티션 수준에서 잠금 에스컬레이션을 설정하여 성능을 향상시킬 수 있습니다. 이렇게 하면 테이블에 대한 잠금 경합을 줄일 수 있습니다. 파티션에 대한 잠금 에스컬레이션을 허용하여 잠금 경합을 줄이려면 ALTER TABLE 문의 LOCK_ESCALATION 옵션을 AUTO로 설정합니다.
구성 요소 및 개념
다음 용어는 테이블 및 인덱스 분할에 적용할 수 있습니다.
파티션 함수
파티션 함수는 분할 열이라는 특정 열의 값을 기준으로 테이블이나 인덱스의 행을 파티션 세트에 매핑하는 방식을 정의하는 데이터베이스 개체입니다. 분할 열의 각 값은 파티션 값을 반환하는 분할 함수에 대한 입력입니다.
파티션 함수는 테이블의 파티션 수와 파티션 경계를 정의합니다. 예를 들어 판매 주문 데이터가 포함된 테이블이 있는 경우 판매 날짜와 같은 datetime 열에 따라 테이블을 12개(월별) 파티션으로 분할할 수 있습니다.
범위 형식(LEFT 또는 RIGHT)은 파티션 함수의 경계 값을 결과 파티션에 배치하는 방법을 지정합니다.
- LEFT 범위는 데이터베이스 엔진에서 간격 값을 왼쪽에서 오른쪽으로 오름차순으로 정렬할 때 경계 값이 경계 값 간격의 왼쪽에 속하도록 지정합니다. 즉, 가장 높은 경계 값이 파티션 내에 포함됩니다.
- RIGHT 범위는 데이터베이스 엔진에서 간격 값을 왼쪽에서 오른쪽으로 오름차순으로 정렬할 때 경계 값이 경계 값 간격의 오른쪽에 속하도록 지정합니다. 즉, 가장 낮은 경계 값이 각 파티션 내에 포함됩니다.
LEFT 또는 RIGHT를 지정하지 않으면 LEFT 범위가 기본값입니다.
예를 들어 다음 파티션 함수는 테이블이나 인덱스를 12개 파티션으로 분할합니다. 즉, 일년의 값을 분할하여 datetime 열에 각 달에 대한 하나의 파티션을 만듭니다. 경계 값이 각 파티션에서 하한 값으로 사용됨을 나타내는 RIGHT 범위가 사용됩니다. RIGHT 범위는 datetime 또는 datetime2 데이터 형식의 열을 기준으로 테이블을 분할할 때 작업하는 것이 더 간단한 경우가 많습니다. 자정 값이 있는 행은 같은 날 이후 값이 있는 행과 동일한 파티션에 저장됩니다. 마찬가지로 날짜의 데이터 형식을 사용하고 월 이상의 파티션을 사용하는 경우 RIGHT 범위는 해당 월의 이후 날짜와 동일한 파티션에 해당 월의 첫째 날을 유지합니다. 이렇게 하면 하루 종일 데이터를 쿼리할 때 파티션을 정확하게 제거하는 데 도움이 됩니다.
CREATE PARTITION FUNCTION [myDateRangePF1] (datetime)
AS RANGE RIGHT FOR VALUES ('2022-02-01', '2022-03-01', '2022-04-01',
'2022-05-01', '2022-06-01', '2022-07-01', '2022-08-01',
'2022-09-01', '2022-10-01', '2022-11-01', '2022-12-01');
다음 표에서는 분할 열 datecol에 대해 이 파티션 함수를 사용하는 테이블 또는 인덱스가 분할되는 방식을 보여줍니다. 2월 1일은 함수에 정의된 첫 번째 경계 지점이므로 파티션 2의 하위 경계 역할을 합니다.
| 파티션 | 1 | 2 | , , | 11 | 12 |
|---|---|---|---|---|---|
| 값 | datecol<2022-02-01 12:00AM |
datecol>= 2022-02-01 12:00AM AND datecol<2022-03-01 12:00AM |
datecol>= 2022-11-01 12:00AM AND col1<2022-12-01 12:00AM |
datecol>= 2022-12-01 12:00AM |
RANGE LEFT 및 RANGE RIGHT의 경우 가장 왼쪽 파티션은 데이터 형식의 최소값을 하한값으로, 맨 오른쪽 파티션은 데이터 형식의 최대값을 상한값으로 사용합니다.
CREATE PARTITION FUNCTION(Transact-SQL)에서 LEFT 및 RIGHT 파티션 함수의 더 많은 예제를 찾습니다.
파티션 구성표
파티션 함수의 파티션을 하나의 파일 그룹 또는 여러 파일 그룹에 매핑하는 데이터베이스 개체인 파티션 구성표를 만들어야 합니다.
CREATE PARTITION SCHEME(Transact-SQL)에서 파티션 구성표를 만드는 예제 구문을 찾습니다.
파일 그룹
파티션을 여러 파일 그룹에 넣는 주된 이유는 파티션 백업 및 복원 작업을 독립적으로 수행하기 위해서입니다. 이는 개별 파일 그룹에 대해 백업을 수행할 수 있기 때문입니다. 계층화된 스토리지를 사용하는 경우 여러 파일 그룹을 사용하면 특정 파티션을 특정 스토리지 계층에 할당할 수 있습니다. 예를 들어 더 느리고 저렴한 스토리지에 이전 및 덜 자주 액세스되는 파티션을 배치할 수 있습니다. 다른 모든 분할 혜택은 사용된 파일 그룹 수 또는 특정 파일 그룹의 파티션 배치에 관계없이 적용됩니다.
분할된 테이블에 대한 파일 및 파일 그룹을 관리하면 시간이 지남에 따라 관리 작업이 상당히 복잡해질 수 있습니다. 백업 및 복원 프로시저가 여러 파일 그룹을 사용하는 데 도움이 되지 않는 경우 모든 파티션에 대해 단일 파일 그룹을 사용하는 것이 좋습니다. 분할되지 않은 개체에 적용되는 것과 동일한 파일 및 파일 그룹 디자인 규칙이 분할된 개체에 적용됩니다.
참고 항목
분할은 Azure SQL 데이터베이스에서 완전히 지원되지 않습니다. Azure SQL 데이터베이스에서 PRIMARY 파일 그룹만 지원되므로 모든 파티션을 PRIMARY 파일 그룹에 배치해야 합니다.
ALTER DATABASE(Transact-SQL) 파일 및 파일 그룹 옵션에서 SQL Server 및 Azure SQL Managed Instance에 대한 파일 그룹을 만드는 예제 코드를 찾습니다.
분할 열
파티션 함수가 테이블 또는 인덱스 분할에 사용하는 테이블 또는 인덱스의 열입니다. 분할 열을 선택할 때 적용되는 고려 사항은 다음과 같습니다.
- 파티션 함수에 참여하는 계산 열은 명시적으로 PERSISTED로 만들어져야 합니다.
- 하나의 열만 파티션 열로 사용할 수 있으므로 경우에 따라 계산 열이 있는 여러 열의 연결이 유용할 수 있습니다.
- 인덱스 키 열로 사용할 수 있는 모든 데이터 형식의 열은 타임스탬프를 제외한 분할 열로 사용할 수 있습니다.
- ntext, text, image, xml, varchar(max), nvarchar(max), varbinary(max)의 LOB(Large Object) 데이터 형식 열은 지정할 수 없습니다.
- Microsoft .NET Framework CLR(공용 언어 런타임) 사용자 정의 형식 및 별칭 데이터 형식 열을 지정할 수 없습니다.
개체를 분할하려면 CREATE TABLE(Transact-SQL), ALTER TABLE(Transact-SQL), CREATE INDEX(Transact-SQL) 문에서 파티션 구성표 및 분할 열을 지정합니다.
비클러스터형 인덱스를 만들 때 partition_scheme_name 또는 filegroup이 지정되지 않고 테이블이 분할된 경우 인덱스는 동일한 분할 열을 사용하여 동일한 파티션 구성표에 기본 테이블로 배치됩니다. 기존 인덱스가 분할되는 방식을 변경하려면 DROP_EXISTING 절과 함께 CREATE INDEX를 사용합니다. 이렇게 하면 분할되지 않은 인덱스 분할, 분할된 인덱스 비 분할 또는 인덱스의 파티션 구성표를 변경할 수 있습니다.
정렬된 인덱스
해당 테이블과 동일한 파티션 구성표를 기반으로 하는 인덱스입니다. 테이블과 해당 인덱스가 정렬된 경우 데이터베이스 엔진은 테이블과 해당 인덱스의 파티션 구조를 유지하면서 테이블 내부 또는 외부의 파티션을 빠르고 효율적으로 전환할 수 있습니다. 인덱스가 기본 테이블에 맞춰지도록 명명된 동일한 파티션 함수에 참여할 필요가 없습니다. 그러나 인덱스와 기본 테이블의 파티션 함수는 기본적으로 동일해야 합니다.
- 파티션 함수의 인수에는 동일한 데이터 형식이 있습니다.
- 같은 수의 파티션을 정의합니다.
- 파티션에 대해 같은 경계 값을 정의합니다.
클러스터형 인덱스 분할
클러스터형 인덱스를 분할하는 경우 클러스터링 키에 분할 열이 포함되어야 합니다. 특수하지 않은 클러스터형 인덱스 분할 및 분할 열이 클러스터링 키에 명시적으로 지정되지 않은 경우 데이터베이스 엔진은 기본적으로 분할 열을 클러스터형 인덱스 키 목록에 추가합니다. 클러스터형 인덱스가 고유한 경우 클러스터형 인덱스 키에 분할 열이 포함되도록 명시적으로 지정해야 합니다. 클러스터형 인덱스와 인덱스 아키텍처에 대한 자세한 내용은 클러스터형 인덱스 디자인 가이드를 참조하세요.
비클러스터형 인덱스 분할
고유한 비클러스터형 인덱스를 분할하는 경우 인덱스 키에 분할 열이 포함되어야 합니다. 비고유 비클러스터형 인덱스를 분할하는 경우 기본적으로 데이터베이스 엔진은 인덱스가 기본 테이블과 정렬되도록 인덱스의 키가 아닌(포함) 열로 분할 열을 추가합니다. 데이터베이스 엔진은 이미 인덱스에 분할 열이 있으면 인덱스에 분할 열을 추가하지 않습니다. 비클러스터형 인덱스 및 인덱스 아키텍처에 대한 자세한 내용은 비클러스터형 인덱스 디자인 지침을 참조하세요.
정렬되지 않은 인덱스
정렬되지 않은 인덱스는 해당 테이블과 다르게 분할됩니다. 즉, 인덱스에는 기본 테이블에서 별도의 파일 그룹 또는 파일 그룹 집합에 배치하는 다른 파티션 구성표가 있습니다. 다음과 같은 경우에는 정렬되지 않은 분할된 인덱스를 디자인하는 것이 유용할 수 있습니다.
- 기본 테이블이 분할되지 않은 경우입니다.
- 인덱스 키는 고유하며 테이블의 분할 열을 포함하지 않습니다.
- 기본 테이블이 서로 다른 조인 열을 사용하여 더 많은 테이블과 함께 조인에 참여하길 원합니다.
파티션 제거
쿼리 최적화 프로그램이 쿼리의 필터 조건을 충족하기 위해 관련 파티션에만 액세스하는 프로세스입니다.
분할된 테이블 및 인덱스의 쿼리 처리 기능 향상에서 파티션 제거 및 관련 개념을 자세히 알아봅니다.
제한 사항
파티션 함수의 범위와 체계는 함수가 생성된 데이터베이스로 제한됩니다. 데이터베이스 내에서 파티션 함수는 다른 함수와 서로 다른 네임스페이스에 있습니다.
분할된 테이블의 행에 분할 열에 NULL이 있는 경우 이러한 행은 가장 왼쪽 파티션에 배치됩니다. 그러나 NULL이 첫 번째 경계 값으로 지정되고 RANGE RIGHT가 파티션 함수 정의에 지정된 경우 가장 왼쪽 파티션은 비어 있고 NULL은 두 번째 파티션에 배치됩니다.
성능 지침
데이터베이스 엔진은 테이블 또는 인덱스당 최대 15,000개의 파티션을 지원합니다. 하지만 1,000개 이상의 파티션을 사용하면 메모리, 분할된 인덱스 작업, DBCC 명령, 쿼리에 영향을 줍니다. 이 섹션에서는 1,000개가 넘는 파티션을 사용할 때 성능에 미치는 영향을 설명하고 필요에 따른 해결 방법을 제공합니다.
분할된 테이블 또는 인덱스당 최대 15,000개의 파티션이 허용되므로 단일 테이블에 장기간 데이터를 저장할 수 있습니다. 하지만 데이터를 필요한 기간 동안만 저장하고 성능과 파티션 수를 균형되게 조정해야 합니다.
메모리 사용량 및 지침
많은 수의 파티션이 사용 중인 경우 16GB 이상의 RAM을 사용하는 것이 좋습니다. 시스템의 메모리가 충분하지 않은 경우 메모리 부족으로 인해 DML(데이터 조작 언어) 문, DDL(데이터 정의 언어) 문 및 기타 작업이 실패할 수 있습니다. 16GB의 RAM으로 많은 메모리 집약적 프로세스를 실행하는 시스템은 많은 수의 파티션에서 실행되는 작업에서 메모리가 부족할 수 있습니다. 따라서 16GB를 초과하는 메모리가 많을수록 성능 및 메모리 문제가 발생할 가능성이 줄어듭니다.
메모리 제한은 분할된 인덱스를 빌드하는 데이터베이스 엔진의 성능 또는 기능에 영향을 줄 수 있습니다. 특히 테이블에 이미 클러스터형 인덱스가 있는 경우 인덱스가 기본 테이블과 정렬되지 않거나 클러스터형 인덱스와 정렬되지 않은 경우에 특히 그렇습니다.
SQL Server 및 Azure SQL Managed Instance에서 index create memory (KB) 서버 구성 옵션을 늘릴 수 있습니다. 자세한 내용은 인덱스 만들기 메모리 서버 구성 옵션 구성을 참조하세요. Azure SQL 데이터베이스의 경우 더 많은 메모리를 할당하기 위해 Azure Portal의 데이터베이스에 대한 서비스 수준 목표를 일시적으로 또는 영구적으로 늘리는 것이 좋습니다.
분할된 인덱스 작업
파티션 수가 1,000개를 초과하는 테이블에서 정렬되지 않은 인덱스를 만들거나 다시 작성할 수 있지만 해당 인덱스는 지원되지 않습니다. 그러면 작업 중에 성능이 저하되거나 메모리가 과도하게 소비될 수 있습니다.
파티션 수가 증가함에 따라 정렬된 인덱스를 만들고 다시 빌드하는 데 더 오래 걸릴 수 있습니다. 성능 및 메모리 문제가 발생할 수 있으므로 여러 개의 인덱스 만들기 및 다시 작성 명령을 동시에 실행하지 않는 것이 좋습니다.
데이터베이스 엔진이 분할된 인덱스를 빌드하기 위해 정렬을 수행하는 경우 먼저 각 파티션에 대해 하나의 정렬 테이블을 빌드합니다. 그런 다음 각 파티션에 있는 각각의 파일 그룹에 정렬 테이블을 만들거나 SORT_IN_TEMPDB 인덱스 옵션이 지정된 경우 tempdb에 정렬 테이블을 만듭니다. 각 정렬 테이블에는 빌드할 최소 메모리 양이 필요합니다. 기본 테이블에 맞게 정렬된 분할된 인덱스를 작성할 때는 정렬 테이블이 한 번에 하나씩 만들어지므로 메모리가 적게 소모됩니다. 그러나 정렬되지 않은 분할된 인덱스를 작성할 때는 모든 정렬 테이블이 동시에 만들어집니다. 따라서 이러한 동시 정렬을 처리하기에 충분한 메모리가 있어야 합니다. 파티션 수가 클수록 더 많은 메모리가 필요합니다. 파티션별 각 정렬 테이블의 최소 크기는 40페이지이며 페이지당 8KB의 용량이 필요합니다. 예를 들어 파티션이 100개인 정렬되지 않은 분할된 인덱스에는 동시에 4,000(40 * 100) 페이지를 직렬로 정렬하기에 충분한 메모리가 필요합니다. 이 메모리를 사용할 수 있는 경우 빌드 작업이 성공하지만 성능이 저하될 수 있습니다. 메모리가 충분하지 않으면 작성 빌드 작업을 수행할 수 없습니다. 또는 파티션이 100개인 정렬된 분할된 인덱스는 정렬이 동시에 수행되지 않으므로 40페이지를 정렬하기에 충분한 메모리만 필요합니다.
데이터베이스 엔진이 다중 프로세서 컴퓨터에서 빌드 작업을 수행할 때 쿼리 병렬 처리를 적용하면 정렬된 인덱스와 정렬되지 않은 인덱스 모두 메모리 요구 사항이 더 커질 수 있습니다. 이는 DOP(병렬 처리 수준)가 클수록 메모리 요구 사항이 커지기 때문입니다. 예를 들어 데이터베이스 엔진이 DOP를 4로 설정하는 경우 파티션이 100개인 정렬되지 않은 분할된 인덱스에는 4개의 프로세서가 동시에 4,000페이지 또는 16,000페이지를 정렬하는 데 충분한 메모리가 필요합니다. 분할된 인덱스가 정렬되어 있는 경우에는 4개의 프로세서에서 40페이지, 즉 160페이지(4*40)를 정렬할 수 있는 메모리 크기만 있으면 됩니다. MAXDOP 인덱스 옵션을 사용하여 병렬 처리 수준을 수동으로 줄일 수 있습니다.
DBCC 명령
파티션 수가 많을수록 DBCC CHECKDB 및 DBCC CHECKTABLE과 같은 DBCC 명령은 파티션 수가 증가함에 따라 실행하는 데 더 오래 걸릴 수 있습니다.
쿼리
테이블 또는 인덱스를 분할한 후 파티션 제거를 사용하는 쿼리는 더 많은 수의 파티션을 사용하여 비교할 수 있거나 향상된 성능을 가질 수 있습니다. 파티션 제거를 사용하지 않는 쿼리는 파티션 수가 증가함에 따라 실행하는 데 시간이 더 오래 걸릴 수 있습니다.
예를 들어 테이블에 1억 개의 행과 열 A, B, C가 있다고 가정합니다.
- 시나리오 1에서는 테이블이
A열에 있는 1,000개의 파티션으로 나뉩니다. - 시나리오 2에서는 테이블이
A열에 있는 10,000개의 파티션으로 나뉩니다.
A열에 대한 WHERE 절 필터링이 있는 테이블의 쿼리는 파티션 제거를 수행하고 하나의 파티션을 검색합니다. 파티션에서 검색할 행이 적기 때문에 시나리오 2에서 동일한 쿼리가 더 빠르게 실행됩니다. B 열에서 필터링하는 WHERE 절이 있는 쿼리는 모든 파티션을 검사합니다. 검사할 파티션이 적기 때문에 시나리오 2보다 시나리오 1에서 쿼리가 더 빠르게 실행됩니다.
분할 열이 아닌 열에서 TOP 또는 MAX/MIN과 같은 연산자를 사용하는 쿼리는 모든 파티션을 평가해야 하므로 분할 성능이 저하될 수 있습니다.
마찬가지로, 단일 행 검색 또는 작은 범위 검색을 수행하는 쿼리는 파티션이 있는 만큼 많은 검색 또는 검색을 수행해야 하므로 쿼리 조건자에 분할 열이 포함되지 않은 경우 분할되지 않은 테이블에 비해 분할된 테이블에 대해 더 오래 걸립니다. 따라서 분할하면 이러한 쿼리가 일반적인 OLTP 시스템의 성능이 거의 향상되지 않습니다.
두 개 이상의 분할된 테이블 간의 동등 조인을 수반하는 쿼리를 자주 실행할 경우 해당 분할 열과 테이블이 조인되는 열이 같아야 합니다. 또한 테이블 또는 해당 인덱스를 함께 배치해야 합니다. 즉, 동일한 이름의 파티션 함수를 사용하거나 기본적으로 동일한 다른 파티션 함수를 사용합니다.
- 분할에 사용되는 매개 변수 수가 같고 해당 매개 변수는 동일한 데이터 형식입니다.
- 같은 수의 파티션을 정의합니다.
- 파티션에 대해 같은 경계 값을 정의합니다.
이러한 방식으로 쿼리 최적화 프로그램은 파티션 자체를 조인할 수 있으므로 조인을 더 빠르게 처리할 수 있습니다. 쿼리가 조인 필드에 배치되지 않았거나 분할되지 않은 두 테이블을 조인하는 경우 파티션이 있으면 실제로 쿼리 처리를 가속화하는 대신 쿼리 처리 속도가 느려질 수 있습니다.
일부 쿼리에서 $PARTITION을 사용하는 것이 유용할 수 있습니다. 자세한 내용은 $PARTITION(Transact-SQL)을 참조하세요.
분할된 테이블 및 인덱스에 대한 병렬 쿼리 실행 전략 및 추가 모범 사례를 포함하여 쿼리 처리의 파티션 처리에 대한 자세한 내용은 분할된 테이블 및 인덱스의 쿼리 처리 기능 향상을 참조하세요.
분할된 인덱스 작업 중 통계 계산에서 동작 변경
Azure SQL 데이터베이스, Azure SQL Managed Instance, SQL Server 2012(11.x) 이상에서는 분할된 인덱스를 만들거나 다시 작성할 때 테이블의 모든 행을 검사하여 통계가 생성되지 않습니다. 대신 쿼리 최적화 프로그램에서 기본 샘플링 알고리즘을 사용하여 통계를 생성합니다.
분할된 인덱스가 있는 데이터베이스를 2012(11.x) 미만의 SQL Server 버전에서 업그레이드한 후 이러한 인덱스에 대한 히스토그램 데이터의 차이를 확인할 수 있습니다. 이러한 동작 변경은 쿼리 성능에 영향을 줄 수 있습니다. 테이블의 모든 행을 검사하여 분할된 인덱스에 대한 통계를 얻으려면 FULLSCAN 절에서 CREATE STATISTICS 또는 UPDATE STATISTICS를 사용합니다.
관련 콘텐츠
다음 문서에서 분할된 테이블 및 인덱스 전략을 자세히 알아보세요.