문제

현재 LAT/Long Float 열이있는 테이블이있는 사이트와 2 개의 열에 대한 인덱스와 검색 해야하는 다른 열의 인덱스가 있습니다.

나는 특정 지점에서 반경에 속하는 행을 얻기 위해이 테이블을 지속적으로 쿼리하고 있습니다 (실제로 속도를 위해 정사각형을 받고 있습니다). 그러나 이미 인덱싱 된 필드 만 필요 하므로이 색인은 실제로 커버링됩니다. 실행 계획에는 2 단계 만 있습니다.

Index Seek  (cost: 100%) and SELECT (cost: 0%)

이제 저는 SQL 2008의 공간적 특징을 활용하려고 노력하고 있습니다. 지리 열을 만들고, 채우고, 공간 색인 인 The Works를 만들었습니다.

그리고 실행 계획에 백만 단계가 있으며 시간의 74%가 클러스터 된 인덱스 탐색에 소비되는 것을 제외하고는 모두 잘 작동합니다. 여기서 공간 색인에서 발견 된 행에 합류하여 나머지는 나머지를 얻습니다. 데이터의 ...
(공간 지수 찾기는 실행 계획 비용의 1%를 차지합니다)

따라서 분명히 공간 색인을 적절하게 사용하고 LAT/Long보다 "일반"색인을 사용하여 이전보다 훨씬 빠른 레코드를 찾는 것입니다. 그러나 메인 테이블에 가입하면 공간 쿼리가 7 배나 걸립니다. 내 오래된 사람이라면.

공간 인덱스에 더 많은 열을 추가하여 덮을 수 있고 이전과 마찬가지로 한 단계로 일을 할 수있는 방법이 있습니까?
이 상황을 개선하기 위해 내가 할 수있는 다른 일이 있습니까?


업데이트 : "일반"인덱스는 포함 된 키워드를 사용하여 "일반"인덱스가 "포함될 수 있음"을 발견했습니다 (알지 못하는 경우 인덱스 자체에 열만 포함 했는 데 사용했습니다).
문서에 따르면 여기,이 조항은 공간 색인에 대한 옵션이 아닙니다 ... 어떤 아이디어가 있습니까?

감사!
다니엘

도움이 되었습니까?

해결책

안타깝게도 현재 커버링 공간 색인을 만들 수있는 방법이 없습니다. 쿼리는 행의 지리 값을 얻기 위해 항상 기본 테이블에 북마크 조회를 수행합니다.

Stintersect의 경우 실제 지리 객체에서 보조 필터를 수행하여 실제로 매개 변수 객체를 교차하는지 확인하기 때문에 항상 필요합니다. 그러나 정확한 답변이 필요하지 않고 Filter ()를 사용할 수있는 경우 기본 테이블을 조회하지 않고 인덱스에서 기본 키 열을 제공 할 수 있습니다. 이것을 지원하는 것은 우리가 다음 릴리스를 위해 고려하고있는 것입니다.

현재 쿼리 속도를 높이는 측면에서 Filter ()를 사용하고 sp_help_geography_index의 출력으로 인덱스를 조정해 보셨습니까?

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top