성능 튜닝 및 인덱싱 전략의 기술로 진입합니다.

제안 된 열을 포함하도록 기존 색인 정의를 수정하는 것이 논리적 인 것 같습니다.

견적을 받아 세 번째 색인 정의를 작성하겠습니다.

create index [idx_index3]
on [table1] (col1, col2, col3)
include (col4, col5, col6....);

CREATE INDEX인용 된 진술에 해당하는 진술 이어야합니다 .

그것은 신중한 해결책 일지 모르지만 그것은 달려 있습니다. 여기에 의존한다고 말하는 몇 가지 예가 있습니다.

다음과 같은 쿼리로 주로 구성된 공통 워크로드가있는 경우 :

select col1, col2, col3
from table1
where col1 = 1
and col2 = 2
and col3 = 3;

그렇다면 당신의 idx_index1지수는 견고 할 것입니다. 완벽하게 좁아서, 외부 데이터가없는 쿼리를 만족시키는 인덱스입니다 (클러스터형 인덱스 정의를 전혀 고려하지 않음).

그러나 주로 다음과 같은 쿼리로 구성된 워크로드가있는 경우 :

select co11, col2, col3, col4, col5
from table1
where col1 = 1
and col2 = 2;

그런 다음 클러스터 인덱스에 대한 키 조회 (또는 힙에 대한 RID 조회)를 필요로하지 idx_index2않는 커버링 인덱스 라고하는 것이 현명 합니다. 비 클러스터형 인덱스 정의에는 쿼리에 필요한 모든 데이터 만 포함됩니다.

권장 사항에 따라 다음과 같은 쿼리에 적합합니다.

select co11, col2, col3, col4, col5
from table1
where col1 = 1
and col2 = 2
and col3 = 3;

여러분의 idx_index3추천은 포함하는 인덱스 것 만족 그 위의 질의에 대한 검색 기준.

내가 얻으려고하는 요점은 이와 같은 고립 된 질문에 있습니다. 우리는 이것을 확실하게 대답 할 수 없습니다. 그것은 모두 공통적이고 빈번한 작업량에 달려 있습니다. 물론 각 샘플 쿼리 유형을 처리하기 위해이 세 가지 인덱스를 모두 항상 정의 할 수 있지만 이러한 인덱스를 업데이트하는 데 필요한 유지 관리에 문제가 생길 수 있습니다 (INSERT, UPDATE, DELETE). 인덱스의 오버 헤드입니다.

워크로드를 분석 및 평가하고 이점이 가장 적합한 위치를 결정해야합니다. 첫 번째 샘플 쿼리가 초당 수십 번 실행되어 가장 흔하고 세 번째 샘플 쿼리와 같이 매우 드문 쿼리가있는 경우 인덱스의 리프 수준 페이지를 부풀려서는 안됩니다. INCLUDE키가 아닌 열. 그것은 모두 당신의 작업량에 달려 있습니다.

신중한 인덱싱 전략을 이해하고 일반적인 작업 부하를 이해하면이 두 가지를 모두 적용하여 가장 좋은 방법을 찾을 수 있습니다.

답변