약 2 백만 개의 레코드가있는 테이블이 있습니다. 경계 상자 이외의 기본값을 사용하여 공간 인덱스를 만듭니다. 일부 쿼리가 매우 빠르며 일부는 매우 느리다는 것을 알고 있습니다. 결정 요인은 쿼리에 사용 된 다각형의 크기로 나타납니다.
더 큰 검색 영역에서를 사용 WITH(INDEX(SIX_FT5))하면 쿼리 속도가 상당히 느려집니다 (0 초에서 15+ 초까지). 더 작은 검색 영역에서는 정반대입니다.
테스트하고있는 쿼리 중 일부는 다음과 같습니다.
빠른:
SELECT TOP(1000) * FROM [FT5] WHERE (shape.STIntersects(geometry::STGeomFromText('POLYGON ((-133462.805381701 -668610.241000959, 2934415.68824241 -668610.241000959, 2934415.68824241 2200521.65831815, -133462.805381701 2200521.65831815, -133462.805381701 -668610.241000959))', 2264)) = 1) 느린:
SELECT TOP(1000) * FROM [FT5] WITH(INDEX(SIX_FT5)) WHERE (shape.STIntersects(geometry::STGeomFromText('POLYGON ((-133462.805381701 -668610.241000959, 2934415.68824241 -668610.241000959, 2934415.68824241 2200521.65831815, -133462.805381701 2200521.65831815, -133462.805381701 -668610.241000959))', 2264)) = 1) 여기 무슨 일인지 아는 사람 있나요?
나는 방금 비슷한 dba.stackexchange.com/questions/61289/를 겪고있었습니다 ... 요 전날 ... 나는 텍스트에서 다각형을 생성하지 않았지만 점과 다각형을 교차 시켰 습니다 ... 공간 인덱스를 사용하도록 지정했습니다. 요점에, 그것은 빠른 속도 결과를 가지고 있었다. 그런 다음 다각형의 공간 인덱스를 사용해 보았고 성능이 매우 떨어졌습니다 ... 문제의 반대와 같습니다.
—
DPSSpatial
당신이 그것에 대해 생각한다면, 검색 봉투의 크기를 변경하면 해야 쿼리에 상당한 영향을 미칠 - 인덱스를 통해 반환되는 많은 행, 느린 응답. 어떤 시점에서는 전체 테이블 스캔이 더 빠르며 봉투를 기준으로 행을 버립니다. 인덱스를 최적화 할 여지가 있으므로 공간 인덱스 옵션에 더 많은 시간을 할애하는 것이 좋습니다.
—
Vince
귀하의 기록이 포인트를 대표합니까? 그것은 언급되지 않았습니다. 또한 사용한 인덱스 생성 구문을 게시 할 수 있습니까? AutoGrid입니까?
—
gischimp
'Geography Auto Gird'와 'Cells per Object'= 4000을 사용했습니다. ~ 45K 다각형과 1 억 1 천만 포인트가 교차했습니다.
—
Michael
기억해야 할 또 다른 사항은 교차가 복잡한 연산이라는 것입니다. 먼저 바인딩 된 요소가 인덱스를 통해 상대적으로 빠른 연산과 교차하는지 확인해야하지만 일치하는 각 항목에 대해 모든 단일 항목이 실제로 교차하는지 계산해야합니다. 폴리곤이 더 복잡하거나 더 많을수록 비용이 더 많이 드는 또 다른 비용이 많이 드는 작업입니다.
—
AKK2