특정 다중 열 인덱스 대신 많은 단일 필드 인덱스를 사용해야합니까?

이 질문은 SQL Server 인덱싱 기술의 효과에 관한 것입니다. 나는 그것이 "인덱스 교차"라고 알려져 있습니다.

많은 성능 및 안정성 문제가있는 기존 SQL Server (2008) 응용 프로그램을 사용하고 있습니다. 개발자는 인덱싱으로 이상한 일을했습니다. 이러한 문제에 대한 결정적인 벤치 마크를 얻지 못했으며 인터넷에서 실제로 훌륭한 문서를 찾을 수 없었습니다.

테이블에는 검색 가능한 많은 열이 있습니다. 개발자는 검색 가능한 각 열마다 단일 열 인덱스를 만들었습니다. 이론은 SQL Server가 이러한 각 인덱스를 결합 (교차)하여 대부분의 상황 에서 테이블에 효율적으로 액세스 할 수 있다는 것 입니다. 다음은 간단한 예입니다 (실제 테이블에는 더 많은 필드가 있음).

CREATE TABLE [dbo].[FatTable](
    [id] [bigint] IDENTITY(1,1) NOT NULL,
    [col1] [nchar](12) NOT NULL,
    [col2] [int] NOT NULL,
    [col3] [varchar](2000) NOT NULL, ...

CREATE NONCLUSTERED INDEX [IndexCol1] ON [dbo].[FatTable]  ( [col1] ASC )
CREATE NONCLUSTERED INDEX [IndexCol2] ON [dbo].[FatTable] ( [col2] ASC )

select * from fattable where col1 = '2004IN' 
select * from fattable where col1 = '2004IN' and col2 = 4

검색 기준을 대상으로하는 여러 열 색인이 훨씬 우수하다고 생각하지만 잘못되었을 수 있습니다. 두 가지 인덱스 탐색에서 SQL Server가 해시 일치를 수행하는 것을 보여주는 쿼리 계획을 보았습니다. 테이블을 어떻게 검색하는지 모르는 경우이 방법이 적합합니까? 감사.

필요한 것은 인덱스 를 다루는 것 입니다. 자체적으로 쿼리를 만족시킬 수있는 인덱스 그러나 '커버링'인덱스에는 한 가지 문제가 있습니다 . 특정 쿼리를 다루고 있습니다 . 따라서 좋은 인덱싱 전략을 개발 하려면 데이터베이스에 어떤 쿼리가 데이터베이스에 충돌 하는지 , 어떤 데이터베이스가 중요하지 않은지, 어떤 유형의 쿼리가 실행되는지 등 의 작업 부하를 이해해야합니다. 이것을 각 인덱스의 쓰기 및 업데이트 비용과 균형을 맞추면 인덱싱 전략이 있습니다. 복잡하게 들리면 복잡하기 때문 입니다 .

그러나 일부 경험 법칙을 적용 할 수 있습니다. MSDN은 기본 사항을 잘 다루고 있습니다.

• 인덱스 디자인 기초
• 일반 인덱스 디자인 지침
• 클러스터형 인덱스 디자인 지침
• 비 클러스터형 인덱스 디자인 지침

예를 들어, 커뮤니티가 제공 한 수많은 기사가 있습니다. 웹 캐스트 녹화 – DBA Darwin Awards : Index Edition .

또한 질문에 구체적으로 답하십시오. 각 열의 선택성 이 높으면 (각각의 값은 데이터베이스에 몇 번만 표시됨) 각 열의 개별 인덱스 가 작동 할 수 있습니다 . 두 인덱스 범위 스캔간에 해시 조인을 사용한 결과 액세스 계획은 일반적으로 매우 잘 작동합니다. 선택성이 낮은 열 (데이터베이스에 각 값이 여러 번 나타나는 별개의 값이 거의 없음)은 자체적으로 인덱싱하는 것이 의미가 없으므로 쿼리 최적화 프로그램은이를 무시합니다. 그러나 선택도가 낮은 열 은 선택성이 높은 열과 쌍을 이룰 때 복합 키가 여러 번 만들어 집니다.