인덱스를 만드는 대신 STATISTICS를 만드는 것이 더 좋은 경우는 언제입니까?

나는에 많은 정보를 발견 한 것 STATISTICS 입니다 : 그들은 그들이 쿼리 나 인덱스에서 수동 또는 자동으로 생성 할 수있는 방법, 유지 관리 등 방법. 그러나, 나는 찾을 수 없었습니다 어떤 관련 지침 또는 "모범 사례"정보이를 만들기 위해 : 인덱스보다 수동으로 생성 된 STATISTICS 객체에서 어떤 상황이 더 유리합니까? 인덱스에 대해 생성 된 통계가 전체 테이블을 다루고 파티션 당이 아니기 때문에 파티션 테이블에 대한 쿼리를 돕는 수동으로 필터링 된 통계를 보았습니다.하지만 통계 개체에서 이익을 얻을 수있는 다른 시나리오가 있어야합니다. 인덱스의 세부 정보가 필요하지 않거나 인덱스 유지 관리 비용이나 가치가없는 차단 / 교착 상태의 비용이 들지 않습니다.

의견에서 @JonathanFite는 인덱스와 통계의 차이점을 언급했습니다.

인덱스는 테이블 자체와 다르게 정렬 된 조회를 작성하여 SQL이 데이터를 더 빨리 찾는 데 도움이됩니다. 통계는 SQL이 쿼리를 충족시키는 데 필요한 메모리 / 노력 량을 결정하는 데 도움이됩니다.

그것은 내 정보를 명확히하는 데 도움이되기 때문에 훌륭한 정보입니다.

어떻게 이런 일을 알고있는 (또는 다른 어떤 기술 정보 않는 것을 S와 어떻게 행동 및 성격에 관한 s의 STATISTICS) 도움을 결정할 때 선택 CREATE STATISTICS을 통해 CREATE INDEX관련 만듭니다 인덱스를 생성 할 때, 특히, STATISTICS객체를? 통계 정보 만 있고 색인이 없으면 어떤 시나리오를 더 잘 사용할 수 있습니까?

가능한 경우 STATISTICS객체가보다 적합한 시나리오의 실제 예제를 작성하는 것이 매우 도움이 될 것입니다 INDEX.

나는 시각적 학습자 / 사상가입니다 때문에, 나는 그것이 사이의 차이를보고 도움이 될 생각 STATISTICS과 INDEX시기를 결정하는 도움의 가능한 수단으로, 나란히, ES를 STATISTICS더 나은 선택입니다.

Thingy           PROs                             CONs
-------          ----------                       -------------------
INDEX            * Can help sorts.                * Takes up space.
                 * Contains data (can             * Needs to be maintained (extra I/O).
                   "cover" a query).              * More chances for blocking / dead-locks.

STATISTICS       * Takes up very little space.    * Cannot help sorts.
                 * Lighter maintenance / won't    * Cannot "cover" queries.
                   slow down DML operations.
                 * Does not increase chances
                   of blocking / dead-locks.

다음은이를 찾는 동안 찾은 일부 리소스입니다.이 동일한 질문을하는 리소스도 있지만 대답하지 않았습니다.

SQL Server 인덱스와 통계

우리가 너무 부끄러워했던 SQL Server 통계 질문

통계. 여러 열 히스토그램이 가능합니까?

** 분명히하기 위해, 나는 이것에 대한 대답이 없으며 실제로 인터 웹에서 정보가 이상하게 누락 된 것으로 보이는 것을 제공하기 위해 소수의 사람들로부터 피드백을 얻고 자합니다.

당신은 질문을 중심으로합니다-통계를 만드는 것보다 인덱스를 만드는 것이 좋은 경우는 언제입니까?

내 SQL Server 내부 노트 (SQLSkills class-IE1 및 IE2) 및 SQL Server 내부 책 에서 아래는 제한적인 이해입니다.

SQL Server 통계는 인덱스 키 값과 일반 열 값에 대한 중요한 정보를 포함하는 시스템 개체 일뿐입니다.

SQL Server는 비용 기반 모델을 사용하여 "충분한"실행 계획을 가능한 한 빨리 선택합니다. 카디널리티 추정 (쿼리 실행의 각 단계에서 처리 될 행 수 추정)은 쿼리 최적화에서 가장 중요한 요소로, 조인 전략, 메모리 부여 요구 사항, 작업자 스레드 선택 및 데이터 액세스시 인덱스 선택에 영향을줍니다. .

SQL Server는 클러스터 번호가 아닌 것으로 추정 할 때 비 클러스터형 인덱스를 사용하지 않습니다. KEY 또는 RID 루프 업 작업이 필요하므로 이러한 추정에 도움이되는 인덱스 (및 열)에 대한 통계를 유지합니다.

통계에 대해 중요한 두 가지가 있습니다.

1. 히스토그램에는 가장 왼쪽의 통계 (인덱스) 열에 대한 데이터 분포에 대한 정보 만 저장됩니다. 또한 키 값의 다중 열 밀도에 대한 정보도 저장합니다. 따라서 히스토그램은 가장 왼쪽의 통계 열에 대해서만 데이터 분포를 저장합니다.

2. SQL Server는 테이블 크기에 관계없이 히스토그램에서 최대 200 단계를 유지합니다. 각 히스토그램 단계에서 다루는 간격은 테이블이 커짐에 따라 증가하여 큰 테이블에 대해 "정확하지 않은"통계로 이어집니다.

   인덱스 선택성은 밀도에 반비례하는 메트릭입니다. 즉, 열의 고유 한 값이 클수록 선택성이 높습니다.

특정 쿼리가 자주 실행되지 않으면 인덱스가 아닌 열 수준 통계를 만들도록 선택할 수 있습니다. 열 수준 통계는 Query Optimizer가 관련된 인덱스 스캔으로 인해 실행 계획이 차선책 임에도 불구하고 더 나은 실행 계획을 찾는 데 도움이됩니다. 동시에 통계는 데이터 수정 작업 중에 오버 헤드를 추가하지 않으며 인덱스 유지 관리를 피하는 데 도움이됩니다. 이 방법은 거의 실행되지 않는 쿼리에 대해서만 작동합니다.

참조 :

• 열 통계 는 Kalen Delaney에 의해 옵티 마이저에게 우위 를 제공합니다
• 통계, 저주받은 거짓말 및 통계 – Statman은 무엇입니까? 코너 커닝엄

참고 : Paul White 또는 Aaron Bertrand 와 같은 사용자는 좋은 질문에 더 많은 색상을 제공하기 위해 소리를 낼 수 있습니다 .

필드 수를 기준으로 데이터 양을 제한하고 올바른 데이터를 신속하게 얻을 수 있어야 할 때 색인이 필요하다고 말하고 싶습니다.

최적의 방식으로 작업을 수행 할 수 있도록 데이터의 특성을 이해하려면 옵티마이 저가 필요할 때 통계가 필요합니다.

내가 알아 낸 것, 필터링 된 통계는 계획에 크게 영향을 미치는 데이터가 왜곡 될 때 도움이됩니다. 예를 들어 스택 오버플로에서 소수의 사용자는 많은 수의 게시물을 가지고 있으므로 사용자 당 평균 게시물 만 사용하는 것이 실제로 가장 좋은 추정은 아닙니다. 따라서 사용자 이름을 기준으로 userId에 대해 필터링 된 통계를 생성 한 다음 SQL Server는이 사용자 이름이 쿼리에있을 때 얻을 수있는 사용자 ID임을 알 수 있어야합니다. 게시물 테이블의 인덱싱 된 필드에는 히스토그램이 존재하기 때문에 해당 ID를 가진 대량의 행이 있습니다. 평균적으로는 그렇게 할 수 없습니다.

Itzik Ben-Gan의 70-461 교육 도서

수동으로 통계를 작성해야하는 몇 가지 이유가 있습니다. 한 가지 예는 조회 술어에 교차 열 관계를 갖는 여러 열이 포함 된 경우입니다. 여러 열에 대한 통계는 쿼리 계획을 개선하는 데 도움이 될 수 있습니다. 여러 열의 통계에는 단일 열 통계에서 사용할 수없는 교차 열 밀도가 포함됩니다. 그러나 열이 이미 동일한 인덱스에 있으면 다중 열 통계 개체가 이미 있으므로 추가 열을 수동으로 만들지 않아야합니다.