하나 또는 두 개의 인덱스?

내 데이터베이스의 테이블에 다음 색인을 만들었습니다.

CREATE INDEX [idx_index1]
on [table1]
(col1, col2, col3)

서버는 다음과 같은 '누락 된'색인을 제안합니다.

CREATE INDEX [idx_index2]
on [table1]
(col1, col2)
INCLUDE (col3, col4, col5, col6....)

유지 관리해야 할 새 인덱스를 만드는 대신 제안 된 열을 포함하도록 기존 인덱스 정의를 수정하는 것이 논리적으로 보입니다. col1 및 col2를 선택하는 쿼리는 index2와 마찬가지로 index1을 사용할 수 있습니다. 내가 맞습니까? 아니면 뭔가 빠졌습니까?

— paulH
소스

답변:

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

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

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

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키가 아닌 열. 그것은 모두 당신의 작업량에 달려 있습니다.

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

— 토마스 스트링거
소스

나는 잠시 동안 그것을 소화해야하지만 좋은 대답처럼 보입니다. 정의한 'index3'에 col3이 동일한 열과 포함 된 열로 있다고 오타라고 가정합니다.

— paulH

네 :-) 잘 잡습니다. 나는 그것을 편집했다.

— 토마스 스트링거

테이블에 열 1-6 만있는 경우 인덱스 1과 2에 대해 어리 석고 3-5를 포함한다는 것은 말할 것도 없습니다.

— 케네스 피셔

@ KennesFisher-왜 바보 같을까요? 데이터베이스 구조와 워크로드가이를 보장 할 경우해야 할 일이 합리적입니다. 예를 들어 1 열과 2 열의 값을 기준으로 1 ~ 5 열을 선택하는 쿼리가 있고 6 열은 인덱스를 늘리지 않으려는 nvarchar (max) 열입니다.

— paulH

@ paulH 아마 내 의견 일지 모르지만 색인에 테이블에 열의 90 + %가 있다는 것을 포함하기에 충분한 열을 추가 한 시점에서 색인을 부풀려서 테이블로 이동하는 지점까지 팽창 시켰습니다. 그 자체가 그렇게 중요한 것은 아닙니다. 이제 확실히 예외가 있습니다. cols 1-5가 모두 int이고 col6이 varchar (max)이면 그렇게 할 수 있습니다. 그러나 일반적으로 나는 그 매우 신중하게 볼 것입니다.

— 케네스 피셔

실제로 정확하고 DBA가 누락 된 인덱스 DMV 등에 의해 제시된 "제안" 을 항상 검토하는 것이 중요한 이유를 발견했습니다 .

누락 된 인덱스 DMV가 제공하는 제안은 따로 제시됩니다. 즉, SQL Server는 다른 인덱스 구조가 무엇이든 관계없이 권장 구조의 인덱스가 쿼리에 도움이된다고 결정했습니다.

— 존 산섬
소스

토마스의 대답이 내포 한 의미 중 하나에 대해 조금 더 :

그는 말했다 :

물론 각 샘플 쿼리 유형을 처리하기 위해이 세 가지 인덱스를 모두 항상 정의 할 수 있지만 이러한 인덱스를 업데이트하는 데 필요한 유지 관리에 문제가 생길 수 있습니다 (INSERT, UPDATE, DELETE). 인덱스의 오버 헤드입니다.

따라서 또 다른 큰 문제는 테이블이 얼마나 자주 업데이트됩니까?

먼저 웹 사이트 소비자 활동을 반영 하는 소매 테이블 과 같이 지속적으로 업데이트 되는 테이블의 예를 고려하십시오 ORDERS. 여기서, 지속적인 업데이트로 수행되는 작업을 증가시키기 때문에 여러 인덱스를 갖는 것에 대해 양심적이기를 원합니다. 데이터베이스 성능에 지속적으로 영향을 미칩니다.

반면, 웹 사이트 설정의 일부로 만 업데이트되는 테이블 ( 대부분의 값은 ONCE 로 업데이트되는 테이블 , 자주 추가되지 않는 값)은 업데이트 속도 저하를 고려 하지 않습니다 . 다중 인덱스는 데이터베이스 인덱스 재 구축 및 재구성 속도를 늦출 수 있지만 충분히 빠르면 FEEL FREE : 다중 인덱스가 읽기 속도를 높이면 계속 진행하십시오.

중간 사례는 일반적으로 배치 프로세스에서 밤새 만 업데이트되는 테이블 일 수 있습니다. 여러 인덱스의 업데이트 속도 저하는 주간 성능에 영향을 미치지 않습니다. (1) 야간 배치 유지 관리를 실행하는 데 (2) 동시 프로세스의 성능 및 (3) 소요 시간에만 영향을 미칩니다. 인덱스 재구성과 같은 데이터베이스 유지 관리 작업 따라서이 3 개 분야의 프로세스가 충분히 빠르게 실행되는 한 ... 쿼리 속도를 높이는 인덱스를 만드십시오.

HTH ...

— Doug_Ivison
소스