테이블 인덱스 성능 향상 관련 문제

Question

처음에는 세 개의 테이블이 있으며 모두 기본 키와 다른 데이터가 있습니다. 이 테이블은 7 천만 개의 행이있는 조인 테이블에 조인됩니다. Table_1, Table_2, Table_3.

Table_3_Id, Table_1_Id, Table_2_Id (이 순서대로)에이 조인 테이블에 기본 키가 있습니다. 또한 채우기 색인이 Table_1_Id, Table_2_Id, Table_3_Id (순서대로) 이상인 클러스터되지 않은 색인이 있습니다.

데이터는 Table_1_Id (이 ID 중 ~ 100 개가 사전 설정되어 있음) 및 (조인을 통해) Table_3의 속성을 사용합니다 (따라서 Table_3_Id를 사용합니다). 그런 다음 Table_1_Id 및 Table_2_Id 값이 반환됩니다. 이 모든 작업은 Entity Framework에서 하나의 쿼리로 수행됩니다.

var items = dataContext.TablesJoin.AsNoTracking() 
      .Join(dataContext.Table_3.AsNoTracking(), x => x.Table_3_Id, x => x.Id, (combi, scan) => new { combi, scan }) 
      .Where(x => possibleIds.Contains(x.combi.Table_1_Id) && otherIds.Contains(x.scan.Other_Id)) 
      .Select(x => new { FirstId = x.combi.Table_1_Id, SecondId = x.combi.DeviceInformationDevices_Id }) 
       ToList(); 

이 구성은 SQL Server Express가 실행되고 있기 때문에, 내가 어떤 공간 문제 (10기가바이트가 최대입니다) 실행 해요 :

이

은 쿼리입니다. 데이터는 약 2GB이지만 기본 키와 색인은 총 5GB입니다. 데이터베이스에 더 많은 데이터가 있기 때문에 성능을 유지하면서 인덱스 크기를 줄이는 데 관심이 있습니다.

모든 것을 살펴본 후에, 정확히 무엇이 사용되는지에 대한 우려가있었습니다. 조인 때문에 클러스터되지 않은 인덱스에 Table_3_Id를 포함시키는 것이 얼마나 유용한 지 분명하지 않습니다. 색인에서이 열을 제거하면 약 1GB의 공간이 절약됩니다.

처음에는이 테이블을 안전한 공간에 클러스터 된 인덱스로 사용했지만 테이블에 많은 삽입 (1000/시간)이 있었기 때문에 모든 디스크 액세스로 인해 테이블이 끊임없이 스왑되므로 데이터 10GB. 이 문제를 해결하기 위해 채우기 비율을 낮추면 (70처럼) 도움이 될까요? 물론, 더 많은 낭비 된 공간을 의미 할 수도 있지만, 이것이 인덱스에 많은 도움을 줄 수 있다면 가치가있을 것입니다.

이 표는 많이 사용되며 성능을 위해 색인이 필요합니다. 인덱스없이 실행하면 몇 분 정도의 시간이 소요되는 반면 인덱스는 2 초 이내에 완료됩니다.

실행 계획 XML : http://pastebin.com/raw.php?i=tfUxgYrK

Answer 1

당신은 고유성에 대한 기본 키가 필요하지 않습니다. NCI는 이미 그 고유성을 제공합니다. 이러한 인덱스 중 하나를 제거 할 수 있습니다. 그러면 공간이 절약됩니다.

다른 인덱스가 클러스터링하여 사용하는 공간을 절약 할 수 있습니다. 외관상으로는 무작위로 위치한 삽입물로 인해 성능 문제가 있음을 알 수 있습니다. 이것은 그럴듯합니다. 삽입이 한 곳 또는 몇 곳에서만 일어나도록 색인의 열 순서를 변경하십시오. 이렇게하면 영향을받는 모든 페이지가 캐싱되는 경향이 있습니다. DML에 필요한 작업 세트는 낮습니다.

DML perf 문제는 아마도 페이지 분할로 인한 것이 아닙니다. 이로 인해 주로 CPU로드 및 조각화가 발생합니다. perf 문제는 디스크에서 임의 페이지를 읽어야하기 때문에 발생했을 수 있습니다.

시간당 1000 개의 삽입물이 많지 않습니다. 작고 완전히 캐싱 된 델타 테이블에 쓰기를 축적하는 것을 고려하십시오. 백그라운드 프로세스에서 행을 주 테이블로 이동하십시오. 그렇게하면 DML 대기 시간이 중요한 경로를 벗어납니다. 선택 사항은 staleness를 허용해야하거나 UNION ALL 델타 테이블을 허용해야합니다.