다중 인덱스 vs 다중 열 인덱스

다중 인덱스 vs 다중 열 인덱스

---

방금 SQL Server 2005의 테이블에 인덱스를 추가했는데 생각이 들었습니다. 색인화하려는 열당 색인이 1 개있는 것보다 1 개의 색인을 생성하는 것과 여러 열을 정의하는 것의 차이점은 무엇입니까?

하나를 다른 것보다 사용해야하는 특정한 이유가 있습니까?

예를 들면

Create NonClustered Index IX_IndexName On TableName
(Column1 Asc, Column2 Asc, Column3 Asc)

대

Create NonClustered Index IX_IndexName1 On TableName
(Column1 Asc)

Create NonClustered Index IX_IndexName2 On TableName
(Column2 Asc)

Create NonClustered Index IX_IndexName3 On TableName
(Column3 Asc)

---

Cade Roux에 동의합니다 .

이 기사는 올바른 길을 안내합니다.

• SQL Server 2005/2008의 인덱스 – 모범 사례, 1 부
• SQL Server 2005/2008의 인덱스 – 2 부 – 내부

한 가지 주목할 점은 클러스터형 인덱스에는 첫 번째 열로 고유 키 (내가 권장하는 ID 열)가 있어야합니다. 기본적으로 인덱스 끝에 데이터를 삽입하는 데 도움이되며 많은 디스크 IO 및 페이지 분할이 발생하지 않습니다.

둘째, 데이터에 다른 인덱스를 만들고 영리하게 구성하면 재사용됩니다.

예를 들어 세 개의 열에있는 테이블을 검색한다고 가정 해보십시오.

주, 카운티, 우편 번호.

• 때때로 주별로 만 검색합니다.
• 때때로 주 및 카운티별로 검색합니다.
• 주, 카운티, 우편 번호로 자주 검색합니다.

그런 다음 주, 카운티, 우편 번호가있는 색인. 이 세 가지 검색 모두에 사용됩니다.

zip만으로 검색하는 경우 zip이 해당 인덱스의 세 번째 부분이고 쿼리 옵티마이 저가 해당 인덱스를 유용하다고 보지 않으므로 위의 인덱스는 SQL Server에서 사용되지 않습니다.

그런 다음이 인스턴스에서 사용되는 Zip에 대한 색인 만 만들 수 있습니다.

그건 그렇고 우리는 Multi-Column 인덱싱을 사용하면 첫 번째 인덱스 열은 항상 검색에 사용할 수 있으며 '상태'로만 검색 할 때 효율적이지만 '상태에 대한 단일 열 인덱스만큼 효율적이지 않습니다. '

나는 당신이 찾고있는 대답은 자주 사용하는 쿼리의 where 절과 group by에 달려 있다는 것입니다.

이 기사는 많은 도움이 될 것입니다. :-)

---

예. 색인에 대한 Kimberly Tripp의 기사 를 확인하는 것이 좋습니다 .

인덱스가 "커버링"이면 인덱스 외에는 아무것도 사용할 필요가 없습니다. SQL Server 2005에서는 키의 일부가 아닌 인덱스에 열을 추가하여 나머지 행으로의 이동을 제거 할 수도 있습니다.

인덱스가 여러 개인 경우 단일 열에 각각 하나의 인덱스 만 사용된다는 의미 일 수 있습니다. 실행 계획을 참조하여 다른 인덱싱 체계가 제공하는 효과를 확인해야합니다.

또한 튜닝 마법사를 사용하여 주어진 쿼리 또는 워크로드가 최상의 성능을 발휘하도록 만드는 인덱스를 결정할 수 있습니다.

---

다중 열 인덱스는 모든 열을 참조 하는 쿼리에 사용할 수 있습니다 .

SELECT *
FROM TableName
WHERE Column1=1 AND Column2=2 AND Column3=3

다중 열 인덱스를 사용하여 직접 조회 할 수 있습니다. 반면에 최대 하나의 단일 열 인덱스를 사용할 수 있습니다 (Column1 = 1 인 모든 레코드를 조회 한 다음 각 레코드에서 Column2 및 Column3을 확인해야 함).

---

One item that seems to have been missed is star transformations. Index Intersection operators resolve the predicate by calculating the set of rows hit by each of the predicates before any I/O is done on the fact table. On a star schema you would index each individual dimension key and the query optimiser can resolve which rows to select by the index intersection computation. The indexes on individual columns give the best flexibility for this.

---

If you have queries that will be frequently using a relatively static set of columns, creating a single covering index that includes them all will improve performance dramatically.

By putting multiple columns in your index, the optimizer will only have to access the table directly if a column is not in the index. I use these a lot in data warehousing. The downside is that doing this can cost a lot of overhead, especially if the data is very volatile.

Creating indexes on single columns is useful for lookup operations frequently found in OLTP systems.

You should ask yourself why you're indexing the columns and how they'll be used. Run some query plans and see when they are being accessed. Index tuning is as much instinct as science.

참고URL : https://stackoverflow.com/questions/179085/multiple-indexes-vs-multi-column-indexes